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
Attachment:
pgp4k58PoYtAd.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
