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

Mon Jan 17 17:23:33 CET 2011

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 ).
+
+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 ).
+
+
+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 ).
+
+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
+
+