Why sign commits — the chain of trust and what signing actually proves

Signing commits and tags extends the chain of trust from the commit hash to a cryptographic identity. An unsigned commit proves only that somebody made the change; a signed commit proves that the holder of this private key made the change.

What a signature extends

An unsigned commit carries three pieces of identity metadata: author name, author email, committer name and email. Every one is a string the engineer typed — there is no cryptographic proof that “Alice” is the same Alice with access to the production repository. A signed commit adds a signature over the commit bytes, produced by a private key whose public half can be looked up in a trust store.

flowchart LR
    A["unsigned commit\nself-asserted"] --> B["signed commit\nsignature + fingerprint"]
    B --> C["verifier checks signature"]
    C --> D["valid + trusted?"]
    D --> E["out-of-band check"]

The verifier’s job is to check that the signature is mathematically valid and that the key fingerprint matches an entry in the trust store. The out-of-band check — publishing the fingerprint through a channel independent of Git — is where the chain of trust becomes a chain of identity. A valid signature by an unknown fingerprint is operationally meaningless.

What signing proves, and what it does not

A signature proves four things and only four: identity at a moment (the keyholder made the commit at this timestamp), integrity (the bytes have not been altered), non- repudiation within the key’s lifetime (the signer cannot credibly deny without claiming compromise), and verifiability by anyone with the public key. It does not prove: that the code is correct, that the commit was reviewed, that the keyholder is trustworthy, or that the key has not been stolen. Cryptographic verification cannot distinguish a legitimate signer from an attacker holding the same private key — key custody is operational, not cryptographic.

The chain of trust

flowchart LR
    A["commit bytes"] --> B["signature"] --> C["key fingerprint"]
    C --> D["trust store entry"] --> E["out-of-band identity"]
    E --> F["trustworthy commit"]

The first two links are cryptographic (git verify-commit, git log --show-signature). The third is lookup against a trust store (GPG keyring or allowedSignersFile). The fourth is publication of the fingerprint through a channel independent of the repository. The fifth is operational policy: the fingerprint belongs to an authorised person on the team today, and the key has not been reported compromised. A break at any link invalidates everything downstream.

Failure modes signing does not prevent

A compromised laptop produces valid signatures (the attacker is the signer). A coerced signer produces valid signatures under duress. A signed merge of unreviewed code carries a signature on the merge, not on the review. A signed tag pointing at an unsigned commit chain is valid for the tag but unattested for the contents. A signed commit by an off-boarded employee is valid until the trust store is updated. Each is an operational failure requiring operational remediation: key rotation, dual-control ceremonies, branch protection, CI ancestry verification, and a joiners-movers-leavers process that touches the trust store on the day of offboarding.

Production discipline

1. Document the trust model. State which keys are trusted, how fingerprints are published, who maintains the trust store.
2. Layer signing with other controls. Branch protection defends review; CI defends correctness; signing defends identity.
3. Audit the trust store on joiners-movers-leavers cadence. Stale trust stores are a chain-of-trust break.
4. Revoke keys the moment they are suspect. Laptop theft, offboarding, suspicious activity.

Cross-course references

• Git, CI/CD & GitOps — Part XXVI-06 (Signing configuration) — the settings that turn cryptography into a default behaviour.
• Git, CI/CD & GitOps — Part XXXII (Protected branches) — branch-protection rules that require signed commits.
• Linux for Production Sysadmins — Part XII (RepositorySecurity) — apt/dnf repository signing, where the same chain applies at the OS-package level.

Quiz