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

[Michael Scherer]

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