>> From: Fabian Stelzer >> >> 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? > Up until now i was not actually aware of the "push signing" functionality in git. I can see that the send/receive-pack use the same api function calls as commit/tag signing. So this should work just as well. Especially if using an ssh agent the whole process is identical to git. I still need to try private key files directly to see how user interaction (like entering a passphrase or touching the U2F Token) would work.