From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110131/002380.html | 144 ++++++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110131/002380.html (limited to 'zarb-ml/mageia-dev/20110131/002380.html') diff --git a/zarb-ml/mageia-dev/20110131/002380.html b/zarb-ml/mageia-dev/20110131/002380.html new file mode 100644 index 000000000..3caf49bf7 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002380.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 04:16:43 CET 2011 +

+
+ +
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 packages at mageia.org.
+ - 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.
+ - 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).
+ - 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
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1