Re: Multiple dev one signing key
On Mon, 11 Mar 2019 12:43, johndoe65...@mail.com said: > Just to be clear, you Werner will sign everything that needs to be > signed for a release with your personal key. In practise that is the case. However, anyone of our small group can sign releases and also update the online list of current version numbers. > As an extra layer of security Niibe will also sign the release and send > you the detacht signature. One signature is actually sufficient but for users of the Web of Trust a second signature might a difference to some. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple dev one signing key
On 3/10/2019 8:29 PM, Werner Koch wrote: > On Fri, 8 Mar 2019 20:05, johndoe65...@mail.com said: > >> What is the best way forward? >> - One signing key accessible on the release system > > I'd say depends on the release system. In most cases this is a > networked box and I would hesitate to do this. Using gpg --with a > remote gpg-agent would be an option, though. > Looks like this approach is out of the question, we are scattered around the world without knowing eatch other in real life! :) >> - Eatch dev having a copy of the key to be able to sign a release > > That is what we do in GnuPG. We have a few core developers which carry > a key and that set of key is distributed with each gpg release and also > via other channels. We also demand that the keys are all smartcard based > and thus a remote key compromise would need physical access. Well, a > developer could be tricked into sign a bad release bu tat leas this > would not compromise the widely distributed key. > > We often add a second signature to a release. For example, I sign many > of the releases and when Niibe-san then sends me his signature for the > same tarball I then append that signature to mine [1]. This is also the > reasons why you often notice changed signature file (you can simply > concatenate detached signatures). For a small group this works really > well, but for a larger group the system Konstantin describes in his mail > is better up to the task. > Just to be clear, you Werner will sign everything that needs to be signed for a release with your personal key. As an extra layer of security Niibe will also sign the release and send you the detacht signature. Is that correct or what am I missing? Thank you Werner for your input, along with Werner's input I'd also like to thank the below two for their input: Daniel Kahn Gillmor Konstantin Ryabitsev -- John Doe ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple dev one signing key
On Fri, 8 Mar 2019 20:05, johndoe65...@mail.com said: > What is the best way forward? > - One signing key accessible on the release system I'd say depends on the release system. In most cases this is a networked box and I would hesitate to do this. Using gpg --with a remote gpg-agent would be an option, though. > - Eatch dev having a copy of the key to be able to sign a release That is what we do in GnuPG. We have a few core developers which carry a key and that set of key is distributed with each gpg release and also via other channels. We also demand that the keys are all smartcard based and thus a remote key compromise would need physical access. Well, a developer could be tricked into sign a bad release bu tat leas this would not compromise the widely distributed key. We often add a second signature to a release. For example, I sign many of the releases and when Niibe-san then sends me his signature for the same tarball I then append that signature to mine [1]. This is also the reasons why you often notice changed signature file (you can simply concatenate detached signatures). For a small group this works really well, but for a larger group the system Konstantin describes in his mail is better up to the task. Shalom-Salam, Werner [1] Using gnupg/build-aux/append-signature.sh -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple dev one signing key
On Fri 2019-03-08 20:05:53 +0100, john doe wrote: > 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 > - Eatch dev having a copy of the key to be able to sign a release > - Other suggestions > > In other words: What is, if any, the best way to sign a file, when the > same key is to be used by multiple persons. This really depends on the development workflow and practices of your team, and the security requirements of your users. So there's no one clear answer. * Does your team have a single release manager, who is responsible for deciding when a release is fully-baked? If so, let the release manager hold the signing key, and no one else. * Do many different people cut releases in your team? If so, you could: a) share a secret signing-capable subkey among all the people who make releases b) if the primary key is signing-capable, share the associated secret key among all the people who make releases. c) make an OpenPGP certificate with multiple signing-capable subkeys, one per release operator * Do you you need *multiple* people to sign off on a release? In that case, you might need some fancier approach (or you might need to modify how your users or downstreams are expected to verify the releases). Does this make sense? Sorry to not have One True Answer™ for you! --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple dev one signing key
On 3/8/2019 2:05 PM, 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 > - Eatch dev having a copy of the key to be able to sign a release > - Other suggestions Each dev just uses their own key to sign a release? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple dev one signing key
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
signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
