[Mageia-dev] PGP keys and package signing

Mon Jan 31 16:03:55 CET 2011

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.
+
+