Why Sign Git Commits

▶ Watch (2:30)

Signing a commit proves possession of a private key at that moment. The real goal is to tie that key to an identity. Without that association, a signature is just a cryptographic artifact. Matthew Garrett argues that the act of signing should provide evidence that a specific person or account controlled the commit. This improves supply chain security by making it harder to inject code after account compromise. Tag signing is common, but commit-by-commit signing can offer stronger guarantees.

The Problem with GPG and X.509

▶ Watch (6:01)

GPG’s web of trust requires finding a trusted signer, a process that went out of fashion in the early 2000s. The model ties signatures to legal identities, not online personas. X.509 certificates for S/MIME require globally trusted CAs. Internal CAs cannot issue signing certificates that GitHub will verify. Short-lived certificates become tedious because users must repeatedly prove email ownership. Both formats lack native support for corporate key management.

SSH Certificates: A Simpler Model

▶ Watch (13:17)

SSH certificates are just SSH key types with embedded public keys and signed metadata. They chain to a single CA of your choice. Git shells out to SSH-Keygen for signing, and SSH agent forwarding works out of the box. No intermediates, no ASN.1. Organizations can issue short-lived certificates that expire naturally, avoiding revocation. Certificates can carry group memberships or path restrictions for fine-grained access control. Hardware-backed keys (TPM, Apple Secure Enclave) integrate directly via the SSH agent.

Putting It Into Practice Today

▶ Watch (26:30)

GitHub does not verify SSH certificate-based commit signatures against a corporate CA. The verified badge only uses GPG keys uploaded to accounts or X.509 certs from global CAs. A workaround is a GitHub Action that inspects every PR commit and validates the signature against your CA. Matthew Garrett’s blog post (linked in the talk) provides code and configuration. Once set, git commit --gpg-sign becomes transparent with auto-signing. Rebase and amend operations resign automatically.

Q&A

Does rebasing locally change the signature? Yes, local rebase commits are signed with the user’s own key, but if GitHub rebases via the API, the resulting commit is signed by GitHub. ▶ Watch (28:53)

Notable Quotes

i really cannot overstate how much i hate GPG Matthew Garrett · ▶ Watch (6:27)

GPG’s trust model bears about as much resemblance to reality as i do to the Mona Lisa Matthew Garrett · ▶ Watch (6:54)

the probability of Outlook suddenly changing how it’s dealing with S/MIME as opposed to preserving backward compatibility with whatever immensely up private PKI someone is using is basically zero Matthew Garrett · ▶ 11:24

the nice thing about SSH ures is that all the SSH tooling treats them pretty much as if they are just public keys Matthew Garrett · t:19

you can add arbitrary messages to this. so you’re going to be able to add a list of group memberships Matthew Garrett · ▶ Watch (24:57)

Key Takeaways

  • SSH certificates are the most practical scheme for organizational git commit signing.
  • GPG and X.509 / S/MIME introduce trust model and CA chain problems.
  • GitHub needs native CA trust for SSH certificates, but custom CI actions work around it.

About the Speaker

Matthew Garrett is an abyss domain expert, and has a long list of recommendations of which portions of the abyss best. He worked on security across hardware to firmware to kernels to applications and everything else.