Signed Commits and Security

Analogy categoryAnalogies

Git records an author name and email on every commit, but neither is verified — anyone can set 'git config user.name' and 'user.email' to any value, including someone else's identity, and Git will happily record it. Commit signing closes this gap by attaching a cryptographic signature to a commit (or tag) using a private key the committer controls, which platforms like GitHub can then verify against a public key on file for that account. A verified signature does not just say 'someone claims to be this person' — it proves the commit was created by whoever holds the corresponding private key, which is a meaningfully stronger guarantee, especially for security-sensitive projects, release tags, or any workflow where supply-chain integrity matters.

🏏

Cricket analogy: Anyone can scrawl 'M.S. Dhoni' on a scoresheet without proof, but a verified fingerprint scan at the pavilion gate proves the person signing in is genuinely him, a far stronger guarantee than a self-reported name.

GPG signing vs SSH signing

Git originally supported signing via GPG (GNU Privacy Guard) keys, which requires generating a GPG keypair, uploading the public key to your Git hosting account, and configuring Git to sign with it. More recently, Git added support for signing commits with SSH keys — the same keys many developers already use for authentication — which lowers the barrier significantly since no separate GPG toolchain is needed. Both approaches produce a cryptographic signature over the commit's content (message, tree, parent, author, committer); the hosting platform then checks that signature against the public key associated with the account and marks the commit 'Verified' in the UI.

🏏

Cricket analogy: A club can authenticate a signed shirt via a notarized certificate requiring a separate process, or by reusing the same biometric ID card players already carry for stadium access; either way the verification desk marks it 'Verified.'

bash

# GPG signing setup
gpg --full-generate-key
gpg --list-secret-keys --keyid-format=long
git config --global user.signingkey 3AA5C34371567BD2
git config --global commit.gpgsign true
git commit -S -m "feat: add rate limiter to auth endpoint"

# SSH signing setup (Git 2.34+)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git commit -S -m "fix: patch CVE-2026-1234 in dependency parser"

# Verify a signature manually
git log --show-signature -1
git verify-commit HEAD

Signing proves who authored the commit content; it says nothing about whether that content is correct or safe. A malicious actor with a legitimately signed commit can still introduce a vulnerability — signing establishes accountability and non-repudiation, not code quality. Treat it as a complement to code review, not a substitute for it.

History rewriting operations — rebase, amend, filter-repo — strip existing signatures from any commit they rewrite, because the signature covers the commit's exact content and parentage, both of which change. Re-signing is required after such operations, and 'git commit --amend --no-edit -S' is a common way to re-sign the most recent commit.

Enforcing signatures and supply-chain security

Signing is only a meaningful guarantee if it is actually verified and enforced somewhere. GitHub branch protection can require that every commit merged into a protected branch be signed and verified, rejecting merges that include unsigned or unverifiable commits. This matters for supply-chain security frameworks like SLSA, which push toward provenance guarantees for every artifact: knowing exactly which verified identity produced each commit that ended up in a release is a foundational piece of being able to answer 'can we trust this build.' Signed tags extend the same guarantee to releases specifically — 'git tag -s v2.4.0' produces a tag whose authenticity can be verified independent of who currently has push access to the repository.

🏏

Cricket analogy: A domestic board can mandate every squad selection sheet be countersigned by a verified manager, rejecting unsigned sheets, so the season's final standings trace back to legitimate selections, just as a signed release tag proves authenticity independent of who holds admin access.

Git's author name and email fields are unauthenticated by default — anyone can set them to anything.
Commit signing (GPG or SSH) cryptographically proves a commit came from the holder of a specific private key.
GitHub marks signed commits 'Verified' after checking the signature against a public key on the account.
Rebasing, amending, or otherwise rewriting a commit strips its existing signature and requires re-signing.
Branch protection can require verified signatures on every commit merged into a protected branch.
Signing proves authorship, not correctness — it complements code review rather than replacing it.

Practice what you learned

1. By default, how does Git verify the author name and email recorded on a commit?

2. What does a 'Verified' badge on a signed commit actually guarantee?

3. Why does rebasing a signed commit invalidate its signature?

4. What Git 2.34+ feature lowered the barrier to commit signing for many developers?

5. In the context of supply-chain security, what is the main value of requiring signed and verified commits on a protected branch?

Was this page helpful?

Branch Protection and CI Checks

Monorepos vs Polyrepos

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Microservices Study Notes

Software Architecture · 30 topics

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Software Engineering Study Notes

Python · 40 topics

Software Engineering

System Design Study Notes

Architecture · 40 topics

Topics covered

#Bash#GitVersionControlStudyNotes#SoftwareEngineering#SignedCommitsAndSecurity#Signed#Commits#Security#GPG#Git#StudyNotes#SkillVeris

Signed Commits and Security