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
