[Mageia-sysadm] [814] - add a module to generate gnupg key ( similar to the one for openssl

Mon Jan 17 17:35:27 CET 2011

On Mon, Jan 17, 2011 at 16:23, Michael Scherer <misc at zarb.org> wrote:
+> Le lundi 17 janvier 2011 à 16:24 +0100, root at mageia.org a écrit :
+>> Revision: 814
+>> Author:   misc
+>> Date:     2011-01-17 16:24:10 +0100 (Mon, 17 Jan 2011)
+>> Log Message:
+>> -----------
+>> - add a module to generate gnupg key ( similar to the one for openssl
+>>   certs )
+>
+> Ok so now we have the command to generate key, I propose to ... generate
+> a key ( we can also party, if we prefer ).
+
+Or both
+
+> We have a few choice to consider :
+> 1) the size of the keys + algo
+>
+> 2) the label of keys and other esthetic detail
+>
+> 3) the number and usage of the keys
+>
+> 4) how do we sign
+>
+> Feel free to repost this mail where it belong ( i think sysadm is a good
+> choice, but I may be wrong ).
+>
+> Size of the keys :
+> ==================
+>
+> For 1, Debian, who is the organization that use the most intensively
+> gnupg among free software user recommend to use RSA 4096 keys
+> ( http://wiki.debian.org/Keysigning &
+> http://lists.debian.org/debian-devel-announce/2010/09/msg00003.html ).
+>
+> So I propose to follow them, RSA. 4096, SHA-2, if supported by our
+> version of rpm.
+>
+> Number and usage of the keys :
+> ==============================
+>
+> On Fedora, there is 1 key per release on the main repository.
+>
+> On Mandriva, there is 1 key for cooker, 1 key for stable, 1 key for
+> security ( and also older keys ).
+>
+> For PLF, there is 1 key for all.
+> ( didn't check for opensuse, but I doubt they diverge from theses 3
+> schemes )
+>
+> 1 key for all is the simplest solution, as this is easiest, and do not
+> requires a lot of work to update keys. There is also a simpler BS.
+> However, this mean we cannot expire the keys. But this also mean that we
+> can more easily have it signed, if we make it signed once, and do not
+> need to redo it every time. ( see the gpg web of trust ).
+
+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.
+
+> People have told me that having separate keys for cooker and stable
+> permit to warn people when they install a rpm from cooker. Personally, I
+> think this doesn't prevent much, an a downside is that people may still
+> install rpm from N+1 on version N, so that lacks coherency.
+>
+> I see not much value into having different keys for secteam than the
+> others, now that the community is everywhere.
+>
+> Moreover, using 1 key for stable and 1 for devel requires us to resign
+> every package, and that always was a time consuming task, who caused
+> trouble in the past ( like problem resigning openoffice ).
+> The same issue regarding expiration apply.
+>
+>
+> Option 3, 1 key for each release permit to have the benefit of
+> separation, and allow us to sign package on the go ( and so notice
+> problem sooner ). However, this requires us to rebuild everything once
+> before the release ( may not be nice for mirrors, as told by Buchan
+> several time ). Another advantage is to be able to expires keys, and
+> adapt us to the growth of computing power quite seamlessly. And we will
+> be less impacted in case of keys being compromised.
+>
+> A disadvantage is that we will have more work to have it certified ( if
+> we want to have it signed ). I was thinking of signing the key every
+> year by debian, ubuntu, fedora and opensuse people, but with this
+> scheme, it is not gonna work well.
+>
+> According to http://www.awe.com/mark/blog/200701300906.html , RH use a
+> master key that sign the release keys. So doing like this would allow us
+> to ask for signing the master key, we can renew it when needed, and we
+> use it to sign the release key. ( RH also have a HSM for that :
+> http://iss.thalesgroup.com/en/Products/Hardware%20Security%
+> 20Modules/nShield%20Solo.aspx , but there is no price tag. If someone by
+> chance know some Thales insider, it would be interesting to have more
+> information ).
+
+Ah that's close to what I was suggesting :)
+Storing it on something like https://store.ironkey.com/personal 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)
+
+> Labels and details
+> ===================
+> Obviously, that's where I expect bike-shedding. I do not care of the
+> name, but obviously, it has to match how we use the key. And I would
+> suggest to make root@$domain for the email, and a generic stuff for the
+> real name.
+>
+> I also guess we should upload it on a public key server.
+>
+> How do we sign
+> ==============
+>
+> Again, point 3 have a impact here. Either we sign when uploaded, using
+> youri, or using a custom action ( as current one do not permit to change
+> uid ), or we use some custom cronjob to sign.
+>
+> Or we sign when the release is made.
+>
+> I would recommend using a custom action, as privilege separation sound
+> like a good idea. I would prefer to avoid signing again the day of
+> release, for reasons that were already given.
+>
+>
+> Bonus, usage of the module :
+> ============================
+>
+>    gnupg::keys { "cauldron":
+>        email => "root@$domain",
+>        key_name => "John the plop",
+>        key_length => "4096"
+>    }
+>
+> create a key cauldron.sec and cauldron.pub in /etc/gnupg/keys/. I am not
+> sure of the format ( maybe have it exported would be good ), and I am
+> not sure that putting everything in this directory is the good location.
+>
+> --
+> Michael Scherer
+>
+> _______________________________________________
+> Mageia-sysadm mailing list
+> Mageia-sysadm at mageia.org
+> https://www.mageia.org/mailman/listinfo/mageia-sysadm
+>
+