[Mageia-dev] PGP keys and package signing

[nicolas vigier]

On Sun, 30 Jan 2011, Motoko-chan wrote:

> On 01/30/2011 07:16 PM, nicolas vigier wrote:
>> So I propose that we use two keys :
>>   - We sign all packages from all repositories using only one key. This
>>     key is stored on the buildsystem. We can call it packages at mageia.org.
> Sounds good to me.
>
>>   - We have an other key, that we call board at mageia.org. This key is
>>     not used on any online server, and is supposed to never be changed,
>>     and should not be compromised. Only a few people have a copy of this
>>     key (some people from board ?), kept on a usb key hidden somewhere, but
>>     not on their laptop or any computer with internet connection. This key
>>     is used to sign the key packages at mageia.org (and revoke it if needed),
>>     and other official keys of the project, but never used for anything
>>     else (not for receiving encrypted messages). And the signature is
>>     sent on public keyservers.
> If possible, using a split key so that no single person can revoke a 
> signature or sign a key would be useful. This would prevent attacks where 
> an individual might be tricked into signing an attacker's key. It would 
> require multiple people to be tricked or have their systems compromised to 
> have that key compromised.

Yes, we could do something like that. Maybe each board member could have
a copy of the key, but encrypted with the key of all other board members,
so that it requires two people to access the key ? Or the people who
have the key don't know the passphrase, and the people who know the
passphrase don't have the key ?
However we should also try to do something simple, to avoid losing
access to the key because it's too complicate.

>>   - We add the board at mageia.org public key inside the urpmi package.
>>     We change urpmi so that it refuses to use any key which has not been
>>     signed by board at mageia.org. And urpmi should frequently update the
>>     keys it is using from public keyservers to check that its signature
>>     from board@ has not been revoked (or that the key self signature has
>>     not been revoked).
> What about third-party repositories, like PLF is to Mandriva? Making that 
> change would require that each of those repository owners have their key 
> signed to work with the urpmi framework. This could either mean the death 
> of urpmi for managing packages, diluting the trust of the board@ key, or 
> discouraging outside contributions.
>
> What if urpmi automatically trusts packages signed with a key signed by 
> board@ and prompt on the first install of a package that is signed by a 
> different key? The yum tool used by Fedora, RHEL, and CentOS works very 
> well by prompting on new keys.

For PLF packages, they will now be included on Mageia repository, so
most users should not need to use external repositories. However we
can add an option or prompt to disable this check, or an option to
manually add a new trusted key. As long as it's not automatically
downloaded from the mirror without asking for any confirmation.

>>   - In case we think the packages@ key may have been compromised, or is
>>     too old, or we want to change it for any other reason, we revoke the
>>     key, and/or revoke the signature from board@ so that it is no
>>     longer accepted by urpmi. We create a new key, we sign it with
>>     the board@ key and we can start to use this new key.
> Sounds good. I'd almost suggest a new packages signing key for each new 
> release that is valid for the supported life of the release plus one year. 
> It's a bit more work, but would reduce the damage a key leak would cause. 
> Unfortunately, this would bring back the problems of re-signing packages 
> when they are turned into a release.

I think we should avoid keys with expiration date because :
 - maybe we will want to extend supported life of the release
 - some people may want to continue using the release after end of life
 - I don't think using expiration date reduce the damage of a leaked
   key. If the key is leaked, we revoke it (or its signature) immediatly
   on all key servers, which should be faster than waiting for the key to
   expire. And replacing an expired key is not more simple than replacing
   a revoked key.

About signing each release with a different key, as they are signed from
the same server, if a key is leaked, the others are likely to be leaked
too, so I don't think it's very useful to use different keys.