On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: > Anthony Towns wrote: >> Oh, the explanation for current practice is that if the key doesn't >> change in practice, apps that look at the keys won't cope well with the >> key changing, and when that becomes important, such as in the event of >> a compromise, we'll have major difficulties in coping. > In that case I suggest you rotate it every month for a few cycles. > BTW, has anyone thought about what will happen when we have a stable > release that has the 200n key in it and 200n+1 rolls around[1]? Will stable > even be installable anymore? How will the updated key be pushed out to > stable quickly enough? Will we have to rebuild CDs and obsolete all the > old ones then too? Is the current scheme of having overlapping > signatures for 1 month long enough, given that stable users might well > only update their machines quarterly or so? We're already doing security rX updates to Sarge anyway, surely we just need to synchronise the key rollover with those releases? And maybe an rX release if the current archive key becomes compromised? And yes, this means old rX release CD images are obsoleted. >_< Maybe the one-true-stable-key idea is the way to go after all... Or maybe an option to apt-key that auto-traces from the key on the CD to the current key, in a sort of certificate chain thingy... But that just reeks of "places to break the chain of trust". -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Anu.edu.au "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Attachment:
pgpyYbXKGYqtd.pgp
Description: PGP signature