Why different keys for -testing and non-testing?

Jesse Keating jkeating at redhat.com
Fri Jan 16 20:38:56 UTC 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090116/3dd4ac85/attachment.bin 


More information about the devel mailing list