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 packa...@mageia.org.
Sounds good to me.
- We have an other key, that we call bo...@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 packa...@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.
- We add the bo...@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 bo...@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.
- 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.
- Michael
