diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2011-January/002156.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2011-January/002156.html | 214 |
1 files changed, 214 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2011-January/002156.html b/zarb-ml/mageia-sysadm/2011-January/002156.html new file mode 100644 index 000000000..ff339d44f --- /dev/null +++ b/zarb-ml/mageia-sysadm/2011-January/002156.html @@ -0,0 +1,214 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20%5B814%5D%20-%20add%20a%20module%20to%20generate%20gnupg%20key%20%28%0A%20similar%20to%20the%20one%20for%20openssl&In-Reply-To=%3CAANLkTim52Yk%3DTK1qAqtChc3fKQs40hv6J-wNwiYHt7Y5%40mail.gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002155.html"> + <LINK REL="Next" HREF="002158.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl</H1> + <B>Pascal Terjan</B> + <A HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20%5B814%5D%20-%20add%20a%20module%20to%20generate%20gnupg%20key%20%28%0A%20similar%20to%20the%20one%20for%20openssl&In-Reply-To=%3CAANLkTim52Yk%3DTK1qAqtChc3fKQs40hv6J-wNwiYHt7Y5%40mail.gmail.com%3E" + TITLE="[Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl">pterjan at gmail.com + </A><BR> + <I>Mon Jan 17 17:35:27 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002155.html">[Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl +</A></li> + <LI>Next message: <A HREF="002158.html">[Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2156">[ date ]</a> + <a href="thread.html#2156">[ thread ]</a> + <a href="subject.html#2156">[ subject ]</a> + <a href="author.html#2156">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Mon, Jan 17, 2011 at 16:23, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">misc at zarb.org</A>> wrote: +><i> Le lundi 17 janvier 2011 à 16:24 +0100, <A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">root at mageia.org</A> a écrit : +</I>>><i> Revision: 814 +</I>>><i> Author:   misc +</I>>><i> Date:     2011-01-17 16:24:10 +0100 (Mon, 17 Jan 2011) +</I>>><i> Log Message: +</I>>><i> ----------- +</I>>><i> - add a module to generate gnupg key ( similar to the one for openssl +</I>>><i>   certs ) +</I>><i> +</I>><i> Ok so now we have the command to generate key, I propose to ... generate +</I>><i> a key ( we can also party, if we prefer ). +</I> +Or both + +><i> We have a few choice to consider : +</I>><i> 1) the size of the keys + algo +</I>><i> +</I>><i> 2) the label of keys and other esthetic detail +</I>><i> +</I>><i> 3) the number and usage of the keys +</I>><i> +</I>><i> 4) how do we sign +</I>><i> +</I>><i> Feel free to repost this mail where it belong ( i think sysadm is a good +</I>><i> choice, but I may be wrong ). +</I>><i> +</I>><i> Size of the keys : +</I>><i> ================== +</I>><i> +</I>><i> For 1, Debian, who is the organization that use the most intensively +</I>><i> gnupg among free software user recommend to use RSA 4096 keys +</I>><i> ( <A HREF="http://wiki.debian.org/Keysigning">http://wiki.debian.org/Keysigning</A> & +</I>><i> <A HREF="http://lists.debian.org/debian-devel-announce/2010/09/msg00003.html">http://lists.debian.org/debian-devel-announce/2010/09/msg00003.html</A> ). +</I>><i> +</I>><i> So I propose to follow them, RSA. 4096, SHA-2, if supported by our +</I>><i> version of rpm. +</I>><i> +</I>><i> Number and usage of the keys : +</I>><i> ============================== +</I>><i> +</I>><i> On Fedora, there is 1 key per release on the main repository. +</I>><i> +</I>><i> On Mandriva, there is 1 key for cooker, 1 key for stable, 1 key for +</I>><i> security ( and also older keys ). +</I>><i> +</I>><i> For PLF, there is 1 key for all. +</I>><i> ( didn't check for opensuse, but I doubt they diverge from theses 3 +</I>><i> schemes ) +</I>><i> +</I>><i> 1 key for all is the simplest solution, as this is easiest, and do not +</I>><i> requires a lot of work to update keys. There is also a simpler BS. +</I>><i> However, this mean we cannot expire the keys. But this also mean that we +</I>><i> can more easily have it signed, if we make it signed once, and do not +</I>><i> need to redo it every time. ( see the gpg web of trust ). +</I> +Another solution is to have one key, signed by everyone and stored +safely (like, on a usb key in a bank), and use this key to sign the +keys that will sign packages (and that will be stored safely too but +have to be accessible on valstar). If we want to use a new key at some +point for signing packages, we just need to access that master key. + +><i> People have told me that having separate keys for cooker and stable +</I>><i> permit to warn people when they install a rpm from cooker. Personally, I +</I>><i> think this doesn't prevent much, an a downside is that people may still +</I>><i> install rpm from N+1 on version N, so that lacks coherency. +</I>><i> +</I>><i> I see not much value into having different keys for secteam than the +</I>><i> others, now that the community is everywhere. +</I>><i> +</I>><i> Moreover, using 1 key for stable and 1 for devel requires us to resign +</I>><i> every package, and that always was a time consuming task, who caused +</I>><i> trouble in the past ( like problem resigning openoffice ). +</I>><i> The same issue regarding expiration apply. +</I>><i> +</I>><i> +</I>><i> Option 3, 1 key for each release permit to have the benefit of +</I>><i> separation, and allow us to sign package on the go ( and so notice +</I>><i> problem sooner ). However, this requires us to rebuild everything once +</I>><i> before the release ( may not be nice for mirrors, as told by Buchan +</I>><i> several time ). Another advantage is to be able to expires keys, and +</I>><i> adapt us to the growth of computing power quite seamlessly. And we will +</I>><i> be less impacted in case of keys being compromised. +</I>><i> +</I>><i> A disadvantage is that we will have more work to have it certified ( if +</I>><i> we want to have it signed ). I was thinking of signing the key every +</I>><i> year by debian, ubuntu, fedora and opensuse people, but with this +</I>><i> scheme, it is not gonna work well. +</I>><i> +</I>><i> According to <A HREF="http://www.awe.com/mark/blog/200701300906.html">http://www.awe.com/mark/blog/200701300906.html</A> , RH use a +</I>><i> master key that sign the release keys. So doing like this would allow us +</I>><i> to ask for signing the master key, we can renew it when needed, and we +</I>><i> use it to sign the release key. ( RH also have a HSM for that : +</I>><i> <A HREF="http://iss.thalesgroup.com/en/Products/Hardware%20Security%">http://iss.thalesgroup.com/en/Products/Hardware%20Security%</A> +</I>><i> 20Modules/nShield%20Solo.aspx , but there is no price tag. If someone by +</I>><i> chance know some Thales insider, it would be interesting to have more +</I>><i> information ). +</I> +Ah that's close to what I was suggesting :) +Storing it on something like <A HREF="https://store.ironkey.com/personal">https://store.ironkey.com/personal</A> would +make sense (hardware encryption, if you try n times (5 or 10 I think) +to unlock with wrong passphrase data is destroyed by the hardware) + +><i> Labels and details +</I>><i> =================== +</I>><i> Obviously, that's where I expect bike-shedding. I do not care of the +</I>><i> name, but obviously, it has to match how we use the key. And I would +</I>><i> suggest to make root@$domain for the email, and a generic stuff for the +</I>><i> real name. +</I>><i> +</I>><i> I also guess we should upload it on a public key server. +</I>><i> +</I>><i> How do we sign +</I>><i> ============== +</I>><i> +</I>><i> Again, point 3 have a impact here. Either we sign when uploaded, using +</I>><i> youri, or using a custom action ( as current one do not permit to change +</I>><i> uid ), or we use some custom cronjob to sign. +</I>><i> +</I>><i> Or we sign when the release is made. +</I>><i> +</I>><i> I would recommend using a custom action, as privilege separation sound +</I>><i> like a good idea. I would prefer to avoid signing again the day of +</I>><i> release, for reasons that were already given. +</I>><i> +</I>><i> +</I>><i> Bonus, usage of the module : +</I>><i> ============================ +</I>><i> +</I>><i>    gnupg::keys { "cauldron": +</I>><i>        email => "root@$domain", +</I>><i>        key_name => "John the plop", +</I>><i>        key_length => "4096" +</I>><i>    } +</I>><i> +</I>><i> create a key cauldron.sec and cauldron.pub in /etc/gnupg/keys/. I am not +</I>><i> sure of the format ( maybe have it exported would be good ), and I am +</I>><i> not sure that putting everything in this directory is the good location. +</I>><i> +</I>><i> -- +</I>><i> Michael Scherer +</I>><i> +</I>><i> _______________________________________________ +</I>><i> Mageia-sysadm mailing list +</I>><i> <A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">Mageia-sysadm at mageia.org</A> +</I>><i> <A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">https://www.mageia.org/mailman/listinfo/mageia-sysadm</A> +</I>><i> +</I></PRE> + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002155.html">[Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl +</A></li> + <LI>Next message: <A HREF="002158.html">[Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2156">[ date ]</a> + <a href="thread.html#2156">[ thread ]</a> + <a href="subject.html#2156">[ subject ]</a> + <a href="author.html#2156">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-sysadm">More information about the Mageia-sysadm +mailing list</a><br> +</body></html> |