On Mon, 14 Feb 2005, Henrique de Moraes Holschuh wrote:
> > Why? What argument is there against a per-release key, including
> > keys for security, testing, unstable, and experimental? It would
> > certainly make things a little easier...
>
> You still need to deal with key revocation and a new key being needed,
> anyway. Yearly changes will not make it more difficult, it will make sure
> those codepaths are tested (and used at least once an year).
It's probably a good idea to create 2 sarge release signing keys, and
include them with the package. Use the first to do everything, and
secret split the second key to n trustworthy developers (k of n split).
Should key #1 get compromised somehow, the backup-key is assembled and
used to sign the Release file from now on. One of the first updates
would probably be the introduction of a new backup key, now that the old
one has been promoted to primary.
A similar 2 key system is probably a good idea for security, and maybe
also for the normal rotated keys (just ship 2005 and 2006 keys now).
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred. | : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `- http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
