What does a verified Git commit signature prove, given that author fields are free text?

## What is actually in a commit Run `git cat-file -p HEAD` and you see the whole commit object: a `tree` line, zero or more `parent` lines, an `author` line with a name, email and timestamp, a `committer` line with the same shape, an optional `gpgsig` header holding the signature, a blank line, and the message. The author and committer lines are ordinary text. Git fills them from `user.name` and `user.email` in configuration, and it never checks them against anything — there is no registry, no authentication step, nothing. `git commit --author="Ada Lovelace <[email protected]>"` writes exactly that, and `GIT_COMMITTER_NAME` and `GIT_COMMITTER_EMAIL` set the other line. Uncontroversially, then, an unsigned commit's stated authorship is a claim by whoever made it, not evidence. ## What signing adds Signing computes a signature over the commit object's content and stores it in the object's header. Because the object id is the hash of that content, the signature and the identity of the commit are bound together: change the message, the tree, a parent, or the author line, and you get a different object whose signature no longer validates. So a verified signature supports exactly this statement: *the holder of key K produced this exact commit object, including its author and committer lines as written, and nobody has altered it since.* Everything else people believe about signed commits is an addition on top of that statement, and each addition needs its own justification. ## The gaps, stated precisely **Signer is not author.** The two are independent fields. A commit whose author line says a colleague's name, signed with your key, verifies perfectly — it just verifies as *your* signature. This is why `%GS` (signer) is a separate placeholder from `%an` (author), and why any policy that says "commits must be signed" without also comparing signer to the claimed identity has left the interesting hole open. **Key is not person.** Verification tells you the signature matches a key. Which human or system that key represents is a mapping you supply — an OpenPGP keyring with trust settings, or a `gpg.ssh.allowedSignersFile` listing principals against public keys. Get that mapping wrong, or accept an unknown key, and the verification is arithmetic without meaning. This is also why an untrusted-but-valid signature has its own status code rather than being reported as good. **Signed is not reviewed, and not safe.** A signature says who produced a change, not that the change is correct, tested, or benign. It is a provenance mechanism, not a quality one. **A signed tip does not mean signed history.** A commit names its parents by hash, so accepting a tip commit accepts that ancestry as content. But nothing requires the ancestors to be signed by anyone. "The tip is signed" and "every commit is signed" are different assertions, and they need different checks. ## Why the distinction matters in practice The common story is a repository where anyone can push and where an attacker — or just a careless script — creates commits attributed to a trusted maintainer. Unsigned, that attribution is free. Signed, the attacker must either use a key you trust or produce a commit that fails verification, so a verifier that compares the signer against a trust list can tell fabricated attribution from the real thing. The converse story is a team that turns on signing and believes the problem is solved while the verification side is never configured — every commit reports as uncheckable, and the signatures are decoration. Signing without verification changes nothing about anyone's security posture. ## What to do with the distinction When you inspect a commit's provenance, look at the signer, not the author: `git log --pretty="%h %an <%ae> | %G? %GS"` puts both on one line and makes divergence obvious. When you define a policy, state it in terms of signers and a trust list. When you rely on a signature, be sure the key-to-principal mapping is something you actually maintain — rotation and revocation are part of the mechanism, not an afterthought. ## Interview framing Start from the object: name the fields, point out that author and committer are unverified config values, then state what the signature binds and enumerate the four gaps — signer versus author, key versus person, provenance versus quality, tip versus history. That order shows you reasoned from Git's data model instead of reciting a slogan.