Jesse Keating wrote:
Currently we have two gpg keys per release, one for
rawhide/updates-testing and one for the final release and stable
updates. This complicates a number of things and I'm really
wondering what is the real actual value we get out of having
multiple keys per release? I have some ideas that I'm going to keep
to myself for right now, but I'd like you, the consumers to help me
understand what value you see in it, and if that value remains if we
were to have a key we applied to all koji builds as the happen which
is different from the 'release' key we'd use at release time and
updates(-testing?) time for each release.
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?
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.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL:
www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Life is the art of drawing without an eraser.
-- John Gardner