Lesson 27 of 30

Commit Signing and Verification

Q: What does commit signing actually prove, and what's the common misconception about GitHub's "Verified" badge?

A strong answer covers: Signing proves the commit content wasn't altered after signing and that it was signed by a specific private key; The misconception: people read "Verified" as proof of real-world author identity, but it only proves the signature matches a public key registered to the account — that key could be freely generated and registered by anyone controlling the account; Contrasts this with unsigned git metadata (user.name/user.email), which git accepts with zero verification; Mentions a practical case where signing matters (release tags, supply-chain-sensitive repos) versus most day-to-day commits where it doesn't.

That green "Verified" badge on GitHub proves a commit's contents haven't been altered — it does not prove the person who wrote the code is who they claim to be.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Commit Signing and Verification

What interviewers actually ask about this, and what a strong answer has to cover.

What does commit signing actually prove, and what's the common misconception about GitHub's "Verified" badge?

A strong answer covers

Signing proves the commit content wasn't altered after signing and that it was signed by a specific private key
The misconception: people read "Verified" as proof of real-world author identity, but it only proves the signature matches a public key registered to the account — that key could be freely generated and registered by anyone controlling the account
Contrasts this with unsigned git metadata (user.name/user.email), which git accepts with zero verification
Mentions a practical case where signing matters (release tags, supply-chain-sensitive repos) versus most day-to-day commits where it doesn't

Likely follow-ups

If I generate a brand-new SSH key, register it to my own GitHub account under a fake display name, and sign commits with it, will they show as Verified? What does that tell you about what the badge is really certifying?
You reworded an old commit with an interactive rebase and now the commit shows as unsigned. Why did that happen, and how would you prevent it?
Would you require signed commits on every repo you work on? What's the actual cost/benefit tradeoff?

The plain-language idea

Anyone can set git config user.name "Linus Torvalds" and user.email to whatever they like, then commit — git will happily record that fabricated identity, no proof required. The name and email on a commit are just metadata the author typed in.

Commit signing fixes a narrower problem than "who wrote this." You generate a cryptographic key (GPG or, more commonly now, an SSH key), tell git to sign your commits with it, and git attaches a signature alongside the commit. Anyone holding your public key can then verify: this exact commit — this tree, this message, this parent — was signed by the private key that matches this public key. If a single byte of the commit changed after signing, the signature no longer validates.

See it in a real thing: signing with an SSH key

Modern git can sign with the same SSH key you already use for pushing — no separate GPG keypair needed:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true   # sign every commit automatically

Now a normal commit gets signed transparently:

git commit -m "fix: handle empty cart state"
git log --show-signature -1

commit 8a3f21c... 
Good "git" signature for adesh@example.com with ED25519 key SHA256:k3F9...
Author: Adesh <adesh@example.com>
Date:   Tue Sep 9 14:02:11 2026 +0530

    fix: handle empty cart state

Push it to GitHub with that same public key added under Settings → SSH and GPG keys → Signing Keys, and the commit shows a green Verified badge in the GitHub UI.

What people usually miss

Watch out

"Verified" proves integrity of the commit content, not the honesty of the identity behind it. It confirms this specific signature matches this specific commit and this registered key — it does not confirm GitHub independently checked that the key's owner is who the email claims. Anyone can generate a key, register it under any email they can add to their own GitHub account, and get a Verified badge on commits with a spoofed user.name.
An unsigned commit isn't necessarily suspicious. Most of git's history — including huge swaths of open source — is unsigned, and that's fine for most projects' threat models. Signing matters most where supply-chain provenance genuinely matters: release tags, security-sensitive repos, anywhere a "who actually authored this" audit trail has real consequences.
Signing doesn't survive a rebase or amend unless re-signed. Rewriting a commit changes its hash, which invalidates the old signature — git commit --amend and git rebase both need commit.gpgsign/--gpg-sign in effect again, or you'll end up with unsigned commits after a rewrite you didn't notice.

The genealogy: the same trust model as HTTPS

This is the same public-key cryptography idea behind an HTTPS certificate or a code-signed installer: a private key you never share proves authorship of something, and a public key anyone can hold lets them verify it without ever needing to trust you directly — they only need to trust that the key is really yours, which is a separate, harder problem signing itself doesn't solve.