Hello, Now that we have a working build system, we need to setup the last part, which is package signing. And for this we need a GPG key. So it's time to decide on some policy about PGP keys.
We can look at how it was done at Mandriva. If I remember correctly : - cooker packages were signed with a key stored on the build system - stable release packages were signed at release time with an other key, not stored on the build system, but stored on the server used to prepare the release and generate the ISOs - updates for main repository were managed by secteam, and signed by secteam key. The secteam didn't use the build system but their own servers, so the key was stored on their servers - updates for contrib repository were signed using a key stored on the build system - backports for main and contrib repository were signed using a key stored on the build system However there are a few problems with this : - too many different keys, with different names, it's difficult to see which ones are really official. - keys stored on the build system were not secure (all contributors and apprentice had shell access on the build system and could easily become root using iurt or other techniques, and then access the secret keys). We won't provide shell access on the same servers as the build system so it should be more secure, however it is always possible that a server be compromised, with all the pgp keys on it, so we should plan for it, and be able to revoke keys if it happens - using a different key for developement version, and released version means we need to resign all packages for the release, taking a lot of time, cpu, and bandwidth to copy the packages between different servers - updates will be done using the same build system, so there is no use to have two different keys for release and updates packages - signed packages are supposed to prevent someone from modifying packages on the mirrors. However the public key used to verify the packages is downloaded from the mirror, and could be modified too. So it would be very easy to create a fake mirror with modified packages. We should fix that by allowing only trusted keys to be used. 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 [email protected]. - We have an other key, that we call [email protected]. 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 [email protected] (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. - We add the [email protected] public key inside the urpmi package. We change urpmi so that it refuses to use any key which has not been signed by [email protected]. 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). - 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. According to this page : http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html there is also a few things we need to improve in urpmi to make it more secure (signed hdlists, and expiration dates on hdlists), but this is for later. In this thread : https://www.mageia.org/pipermail/mageia-dev/20110128/002363.html misc proposed that we publish tarballs of our software on the mirrors, and sign them using a pgp key. So we need a key for that. We also want to sign ISOs, maybe with a different key. So I think we can do the same as for packages key, we create new keys for software releases and for ISOs, and we sign those keys with the board@ key. And we can tell everybody that all files released by the project are always signed by a key that was signed by the board@ key. If we decide to do this, someone from board could generate the key next week at fosdem after the election, save it on usb key for other board members, and give the fingerprint to everybody to sign the key. Any opinions on this ? Or other ideas ? Or comments ? Nicolas
