diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110131/002380.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110131/002380.html | 144 |
1 files changed, 144 insertions, 0 deletions
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 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] PGP keys and package signing + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C20110131031643.GF21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + + <LINK REL="Next" HREF="002381.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] PGP keys and package signing</H1> + <B>nicolas vigier</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C20110131031643.GF21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] PGP keys and package signing">boklm at mars-attacks.org + </A><BR> + <I>Mon Jan 31 04:16:43 CET 2011</I> + <P><UL> + + <LI>Next message: <A HREF="002381.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2380">[ date ]</a> + <a href="thread.html#2380">[ thread ]</a> + <a href="subject.html#2380">[ subject ]</a> + <a href="author.html#2380">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>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 <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">packages at mageia.org.</A> + - We have an other key, that we call <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">board at mageia.org.</A> 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 <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">packages at mageia.org</A> (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 <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">board at mageia.org</A> public key inside the urpmi package. + We change urpmi so that it refuses to use any key which has not been + signed by <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">board at mageia.org.</A> 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 : +<A HREF="http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html">http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html</A> +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 : +<A HREF="https://www.mageia.org/pipermail/mageia-dev/20110128/002363.html">https://www.mageia.org/pipermail/mageia-dev/20110128/002363.html</A> +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 + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + + <LI>Next message: <A HREF="002381.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2380">[ date ]</a> + <a href="thread.html#2380">[ thread ]</a> + <a href="subject.html#2380">[ subject ]</a> + <a href="author.html#2380">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |