New Key Repo Locations

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20080829/c0f25d57/attachment.bin