Multiple dev one signing key

[Konstantin Ryabitsev]

On Fri, Mar 08, 2019 at 08:05:53PM +0100, john doe wrote:
>Hi,
>
>I'm considering working  on a project that has only for now a couple of
>developers.
>As part of that project everything that will be released will need to be
>gpg signed.
>
>What is the best way forward?
>- One signing key accessible on the release system
>- Each dev having a copy of the key to be able to sign a release
>- Other suggestions

From the perspective of kernel.org, we've tried very hard not to have 
signing keys residing on any kind of centrally managed infrastructure.  
The general rule is that we place trust into developers, not into 
infrastructure or systems admins.

Therefore, all tags and tarball releases are signed by developers 
themselves, using their own PGP keys, and those keys are signed by the 
lead developer (i.e. everyone signing tags on kernel.org can trace their 
key via the web of trust to Linus Torvalds). So, if anyone wants to 
verify a tag or a tarball sig, they can trace that developer's key to 
Linus. I'm willing to bet that this happens extremely rarely, if ever -- 
most people just use "Trust On First Use."

If, for some reason, you can't use this approach and all your releases 
must be signed by the same key, a solution I can suggest is having a 
single Certify ("master") key with multiple Signing subkeys. Each 
developer is given their own Signing subkey, but not the master key.  
The master private key is kept offline with the passphrase split between 
multiple members of the project using something like Shamir's Secret 
Sharing. When someone new joins the team, a new Signing subkey is 
created and given to them, and if someone leaves, then their subkey is 
revoked.

There are downsides to this approach -- for example, everyone would need 
to remember to refresh the pubkey regularly in order to get information 
about new and revoked signing subkeys. If they don't do that, the 
signatures would fail to verify due to "unknown key" error -- so if your 
intended target for these signatures if the public at large, then you 
are likely to have a lot of confusion about what is going on.

Anyway, I don't recommend having central infrastructure storing private 
keys -- unless you invest a lot of effort into setting that up properly, 
that's going to be a very interesting target for attackers to get into.

Best,
-K

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190308/e614b9b0/attachment-0001.sig>