On Fri, 2009-01-16 at 15:16 -0500, Todd Zullinger wrote: > One advantage (which may or may not be enough to warrant keeping the > keys separate) is that if you want to ensure no packages from > updates-testing are installed on a box, you can easily do so by not > importing the testing key. I don't think any of the tools > automatically import keys without prompting, the user, correct? That's correct. We could still accomplish this by having 1) a key that is applied to any build that comes from an official koji build. 2) Only apply a releases key to a package that was in the GOLD release, and those packages which migrate to stable updates. If you don't trust the koji key, you'll only ever get something that has been "blessed" by a human. > I'm more curious whether the plan going forward is to generate a new > key for each release or if that was just a temporary situation due to > the infrastructure intrusion last August. I think it adds a little > bit of confidence when the signing key remains the same for a > reasonably long time (certainly more than the life of one release). > On the other hand, the lack of any way to revoke a key in the rpm db > is problematic and cycling the keys once per release does mitigate > this a little. Given that we can't revoke, yes, we plan to use new keys each release. We can use gpg web-o-trust thing and sign the new keys with the old keys and whatnot, does that actually help people? I guess we really need to understand what it is that signing gives us. At a basic level, the gpg signature says that "this package came from Fedora". That has an extreme amount of value to it, as you state you can trust only that key (set) and get only packages that came from Fedora. We've tried to go a bit further and apply status to the keys to indicate "this is a test package that came from Fedora" vs "this is a stable package that came from Fedora", to allow you to get even more fine tuned with your trust. Is there anything else we're getting out of these keys? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
