diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110131/002389.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110131/002389.html | 134 |
1 files changed, 134 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110131/002389.html b/zarb-ml/mageia-dev/20110131/002389.html new file mode 100644 index 000000000..2f189a0d5 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002389.html @@ -0,0 +1,134 @@ +<!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=%3C20110131150355.GH21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002385.html"> + <LINK REL="Next" HREF="002390.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=%3C20110131150355.GH21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] PGP keys and package signing">boklm at mars-attacks.org + </A><BR> + <I>Mon Jan 31 16:03:55 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002385.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002390.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2389">[ date ]</a> + <a href="thread.html#2389">[ thread ]</a> + <a href="subject.html#2389">[ subject ]</a> + <a href="author.html#2389">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sun, 30 Jan 2011, Motoko-chan wrote: + +><i> On 01/30/2011 07:16 PM, nicolas vigier wrote: +</I>>><i> So I propose that we use two keys : +</I>>><i> - We sign all packages from all repositories using only one key. This +</I>>><i> 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> +</I>><i> Sounds good to me. +</I>><i> +</I>>><i> - 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 +</I>>><i> not used on any online server, and is supposed to never be changed, +</I>>><i> and should not be compromised. Only a few people have a copy of this +</I>>><i> key (some people from board ?), kept on a usb key hidden somewhere, but +</I>>><i> not on their laptop or any computer with internet connection. This key +</I>>><i> 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), +</I>>><i> and other official keys of the project, but never used for anything +</I>>><i> else (not for receiving encrypted messages). And the signature is +</I>>><i> sent on public keyservers. +</I>><i> If possible, using a split key so that no single person can revoke a +</I>><i> signature or sign a key would be useful. This would prevent attacks where +</I>><i> an individual might be tricked into signing an attacker's key. It would +</I>><i> require multiple people to be tricked or have their systems compromised to +</I>><i> have that key compromised. +</I> +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. + +>><i> - We add the <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">board at mageia.org</A> public key inside the urpmi package. +</I>>><i> We change urpmi so that it refuses to use any key which has not been +</I>>><i> signed by <A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">board at mageia.org.</A> And urpmi should frequently update the +</I>>><i> keys it is using from public keyservers to check that its signature +</I>>><i> from board@ has not been revoked (or that the key self signature has +</I>>><i> not been revoked). +</I>><i> What about third-party repositories, like PLF is to Mandriva? Making that +</I>><i> change would require that each of those repository owners have their key +</I>><i> signed to work with the urpmi framework. This could either mean the death +</I>><i> of urpmi for managing packages, diluting the trust of the board@ key, or +</I>><i> discouraging outside contributions. +</I>><i> +</I>><i> What if urpmi automatically trusts packages signed with a key signed by +</I>><i> board@ and prompt on the first install of a package that is signed by a +</I>><i> different key? The yum tool used by Fedora, RHEL, and CentOS works very +</I>><i> well by prompting on new keys. +</I> +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. + +>><i> - In case we think the packages@ key may have been compromised, or is +</I>>><i> too old, or we want to change it for any other reason, we revoke the +</I>>><i> key, and/or revoke the signature from board@ so that it is no +</I>>><i> longer accepted by urpmi. We create a new key, we sign it with +</I>>><i> the board@ key and we can start to use this new key. +</I>><i> Sounds good. I'd almost suggest a new packages signing key for each new +</I>><i> release that is valid for the supported life of the release plus one year. +</I>><i> It's a bit more work, but would reduce the damage a key leak would cause. +</I>><i> Unfortunately, this would bring back the problems of re-signing packages +</I>><i> when they are turned into a release. +</I> +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. + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002385.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002390.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2389">[ date ]</a> + <a href="thread.html#2389">[ thread ]</a> + <a href="subject.html#2389">[ subject ]</a> + <a href="author.html#2389">[ 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> |