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.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?
So this should work just as well. Especially if using an ssh agent the wholeprocess 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.
<<attachment: smime.p7s>>
