On Wed, 6 Jul 2011 09:48:24 +0200, MT (Miloslav) wrote: > > On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote: > >> > 2) We don't have a system to validate a gpg signature in place. My > >> > understanding of GPG is that we would need to house all the public keys > >> > to validate against. Nothing like this exists. I'm lazy and don't feel > >> > like creating such a system. :) > >> > >> 2) ditto - we can 'house' them in so far as including them as package > >> sources. If they aren't included then don't run the check. If they are, > >> run the check... > > > > If we include the whole show in the src.rpm, how does that add any safety? > It can protect Fedora against substituted upstream tarballs (i.e. if > the new upstream version has an incorrect signature, we would notice). The packager should have noticed already. If the sig file is added to the src.rpm and the public key has been added to it [a long time] before, all AutoQA would add is to detect the case when the packager added a new tarball+sig without verifying it beforehand. Right? > > Doesn't that make it easier to compromise the src.rpm by replacing > > tarball, sig, and key? > That's "protecting Fedora users against substituted Fedora RPMs", > which is quite orthogonal to protecting Fedora against upstream > tarballs. If it's possible to hack a web page and replace a tarball, it would also be possible to replace a detached sig file (or even add a faked one for the first time and pretend that it's a new feature of the release process). It wouldn't be the first project where the signer and/or the signing key has changed, and where the downloader needs to decide on whether to trust the key that has been used. That is, not just use --recv-keys to fetch it from a key server. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
