Re: Should Fedora rpms be signed?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 1 Nov 2004, Peter Jones wrote:

> On Mon, 2004-11-01 at 12:24 -0600, Satish Balay wrote:
> >
> > Are you saying - currently when a package is gpg-signed by a person -
> > he/she actually goes through a manual process of verifying the
> > following?
> > 
> > - source is not tampered (including the intial .tar.gz, patches, .spec files)
> > - binary is not tampered
> > - source -> binary process didn't introduce 'ANY' tampering?
> 
> I'm saying that when we release signed packages as Fedora or as Red Hat,
> we are acknowledging that we intend for all of these to be the case, and
> that we believe they are.  That is to say that when we distribute a
> signed package it generally holds true, and is assumed to be true, that:
> 
> - we've not included malicious code from the upstream
> - we don't think there are negative legal ramifications of
>   us distributing that package in the distro
> - the source has not been maliciously tampered while retrieving
>   it from the upstream source
> - the packaging itself is reasonable and will not harm your system
>   when used appropriately
> - the process of compiling it did not introduce harmful changes
>   which should have or could have been known ahead of time (that is,
>   that the build environment can be trusted not to introduce problems)
> - for Fedora Core packages, the packages are free software
> - the packages are really from us (the signer)
> 
> This is at least the case when we release a distro, a release candidate,
> or a test release in which the packages are signed.  And in the very
> minor variations where one of these points isn't the case, the
> perception is still that they all are.  That's what's important here,
> not the intent.  If the intent isn't perfectly clear when looking at the
> data and the tools, then it doesn't make any difference to our users.

Ok - I had to respond to this. 

The correct thing to do is to document the above text for EACH gpg-key
redhat uses. Saying the text is the SAME for ALL keys (hence can't
sign rawhide) is wrong.

And you haven't specified what the gpg-singer does (the process he
uses) to provide the above checks before signing.

> 
> I further stipulate that unless there is actually some observable,
> immutable data to signify that a signature means only that the source
> has been verified, many users will assume that any signature represents
> _all_ of these things, and they are justified in this assumption.

There will always be wrong assumption. The fix is documentation.

> The problem that people are hoping to address is inconvenience of
> testing rawhide packages because they are not signed.  Right now,
> package update tools have no option but to check both if the package
> data is correct and if the package is the one intended to be in the
> repo.
> 
> Update tool authors resist making signature checking configurable on a
> per-repo basis, which would alleviate the strain but reduce the overall
> utility of the tools.  

yum has an option to do independent 'gpg-checks' on each repository. So this
is not the problem.

> At the same time, users of rawhide and update
> tools really only care that the package is from the repo, not anything
> else.  So the best answer, IMO, is to make it so that you can say "this
> is the right package" without all of the other implications, and then to
> change the update tools so that you *can* say "for this repo, I only
> care that the package is really from the repo".  We don't need to check
> our traditional "package signature" per se; we need to check only that

Now you are coming up with a complex system just to justfy using
multiple gpg-keys with the exact same meaning.

I'll stop now.
Satish


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]