Jesse Keating wrote: > As I mentioned in an earlier thread I was interested in reducing the > number of gpg keys down to one per release. Currently we have two, one > we sign development builds with during beta/preview and updates-testing, > and then one we sign the released packages with and the stable updates > with. Multiple keys per release creates a lot of churn, reduces the > number of hardlinks we can maintain, and causes a lot of delay in > getting package sets prepped for the different releases. As such I'm > proposing that we reduce the keys down to one per release, used for all > the scenarios listed, starting with Fedora 11. Would it make sense from a security and release standpoint to still have two keys but to divide their use differently? Key 1 is for beta/preview/release. Key 2 is for updates-testing/updates. It seems like this would prevent most of the churn surrounding resigning since the resigning happens between packages from (beta => preview => release) and (updates-testing => updates) rather than (release => updates). It would also mean that we could create a revocation certificate for Key 1 and then delete the private key after beta/preview/release. That would limit the time a malicious party could compromise the key used to sign rpms on media and in the release tree which seems like it would give us a better chance of having a known good base should we ever be faced with distrusting packages that made it into our repository. Security is hard, though, so maybe someone can point out an error in my thinking :-) -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
