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
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?