Why different keys for -testing and non-testing?

[Todd Zullinger]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090116/334b89dd/attachment.bin