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