How would you roll out commit signing across a team, and what does it actually buy?

## Decide what you are trying to prove Before any configuration, write down the claim. Usually it is one of: *every change that reached production came from a key we recognise*, or *this release artifact was cut by our release process*, or *fabricated authorship is detectable*. Those need different amounts of machinery, and the second is far cheaper than the first. Without that statement, teams turn on `commit.gpgSign` and get a repository full of signatures that nothing verifies — pure ceremony. ## A staged rollout **Stage one: sign release tags.** Annotated tags signed with `git tag -s` are the highest-value, lowest-friction step. There are few of them, they are created by a small number of people or by one release process, and they are what downstream consumers actually pin. The release script verifies with `git verify-tag` and refuses to build on a non-zero exit. **Stage two: sign commits, opt-in.** Get maintainers signing with `commit.gpgSign` and collect the keys. Nothing is enforced yet; you are building and testing the trust list. **Stage three: verify on the branches you protect.** Only now does a check exist that can block. Whatever runs that check must fail closed — treating "cannot check" as a pass is the failure mode that makes the whole programme theatre. ## The trust list is the project Verification compares a signature against a public key and needs an assertion about who that key belongs to. With OpenPGP that is a keyring plus trust settings; with SSH signing it is the file named by `gpg.ssh.allowedSignersFile`, whose lines pair a principal with a public key under the `git` namespace, and optionally a `gpg.ssh.revocationFile` listing keys that must be rejected. That file is an access-control artifact with a lifecycle: it changes on every join and departure, it must be distributed to every place verification happens, and it needs a review path of its own — whoever can add a line to it can add a trusted signer. Many teams keep it in a repository so changes are reviewable and auditable. Plan rotation before the first key expires, not after, and rehearse the case where a key must be revoked immediately. ## What signing does and does not buy **Buys:** a checkable link from a commit to a key holder, which makes fabricated authorship detectable rather than free; tamper-evidence for content served through mirrors or untrusted paths; a defensible provenance story for release artifacts. **Does not buy:** protection from a compromised developer machine, where the key and its agent live and an attacker can simply sign; any statement about code quality or review; retroactive protection for history created before the programme; protection from a trusted signer acting badly. State these plainly when the requirement arrives from a compliance direction, because "we require signed commits" is often bought as a security control when what it delivers is attribution. ## Friction to budget for - **Rewrites drop signatures.** Amend, rebase and cherry-pick create new commit objects, so a rewrite-heavy workflow needs signing to be automatic (`commit.gpgSign`) or it will be forgotten. - **Automation needs identities.** Bots, release jobs and merge automation that create commits need their own keys and their own entries in the trust list, with a decision about where that key material lives. - **Passphrase prompts.** A long rebase is one signing operation per commit; without an agent this is unbearable, and people will disable signing rather than endure it. - **Onboarding.** Every new machine needs key setup, and every new person needs a trust-list entry. If that takes a week, people work around it. - **Enforcement lives outside Git.** Git itself gives you commands to sign and verify; making the rule mandatory requires a gate on the receiving side, and choosing and operating that gate is a separate decision from anything in the repository. ## How to know it is working Audit rather than assume: walk the range on protected branches with `git log --pretty="%h %G? %GS %s"` and confirm the signer column is populated and matches the trust list, and confirm that a deliberately unsigned commit is actually rejected by the gate. A programme nobody has tested with a negative case has not been tested. ## Interview framing The answer that reads as principal-level is not the config — it is the sequencing (tags before commits), the recognition that the trust list is the real system with a real lifecycle, the honest threat-model boundaries, and the insistence that verification fail closed and be tested with a negative case.