On Fri, Aug 29, 2008 at 03:42:31PM +0200, Jeroen van Meeuwen wrote: > Axel Thimm wrote: >> On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote: >>> Axel Thimm wrote: >>>> W/o knowing all details, why not move os to os.oldkey and use os as >>>> the new key's content? If the key is considered compromised what >>>> mirror admin would like to keep the old signed packages around anyhow? >>>> >>> I think then the problem becomes that every existing installation >>> points to os/ where it would need os.oldkey/ to get the packages it >>> can check gpg keys on. >> >> But isn't this desired behaviour? We don't actually want os.oldkey/ to >> be used anymore (mid-term) as we need to revoce the key in case it has >> been stolen. Maybe we don't need os.*key at all. >> >> E.g. if a key has been stolen, burn all signed stuff and recreate them >> with a new key. >> > > The problem then becomes that a fedora-release package update needs to > come from the old location which is the only location a currently > running client knows about, signed with the old key (which again is all > the running client knows about at this point). If ATM the key is considered stolen, the users need to stop using the key immediately anyway. Issuing a new package signed with the old key is just keeping the racing window open. IOW the users do need to acknowledge the change of keys (like you do when an ssh host key has been changed). Otherwise any user with an F9 DVD is susceptible for being spoofed anyway, we won't be able to cure that: The people that stole the key just need to get control over a mirror or even worse officially setup a mirror of their own and distribute their own content signed with the stolen key! The only way to not have this happen is to loudly announce that the old key is being revoked and content signed with it needs to be cast away and replaced. All this assumes that there is real suspicion that the old key has been stolen, but the new key procedure does indicate that case. Otherwise, if it is just being done for good measure, then it's a bad step. -- Axel.Thimm at ATrpms.net
Attachment:
pgp6Gp9iksMTp.pgp
Description: PGP signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list