On Tue, Jul 6, 2021 at 10:20 AM Fabian Stelzer via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > From: Fabian Stelzer <fs@xxxxxxxxxxxx> > > set gpg.format = ssh and user.signingkey to a ssh public key string (like from an > authorized_keys file) and commits/tags can be signed using the private > key from your ssh-agent. > > Verification uses a allowed_signers_file (see ssh-keygen(1)) which > defaults to .gitsigners but can be set via gpg.ssh.allowedsigners > A possible gpg.ssh.revocationfile is also passed to ssh-keygen on > verification. > ... > In our corporate environemnt we use PIV x509 Certs on Yubikeys for email > signing/encryption and ssh keys which i think is quite common (at least > for the email part). This way we can establish the correct trust for the > SSH Keys without setting up a separate GPG Infrastructure (which is > still quite painful for users) or implementing x509 signing support for > git (which lacks good forwarding mechanisms). Using ssh agent forwarding > makes this feature easily usable in todays development environments > where code is often checked out in remote VMs / containers. Thanks for working on this, and I support this initiative. I coincidentally have started proselytizing something similar just weeks ago. My interest is in signing pushes rather than commits/tags, as that (in combination with SSH U2F support) provides a simple mechanism to require (forwardable!) 2-factor authentication on pushes over HTTP. I haven't looked at the signing code in detail, but I had the impression that adding SSH signatures would automatically also add support for signed pushes? (aka. push-certs) Do you know? -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
