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

[Pascal Terjan]

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
>