Git and GitHub / Advanced: trust, scale, and recovery / Lesson 14

Commit signing, verification, and trust

Interpret signatures as bounded identity evidence without confusing them with code quality or repository authorization.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Separate author text, signature validity, trust, and write permission.
Review verification context and key lifecycle requirements.

State what a signature supports

Commit author and committer fields are ordinary metadata and can be supplied independently of remote login. A cryptographic signature can bind signed commit data to a key under a verification method. Trust additionally asks whether that key belongs to an approved identity and is acceptable for this purpose. Neither a valid signature nor a GitHub Verified label proves the code is correct, reviewed, or safe to execute. Write permission and branch policy are separate server controls. Keep these claims distinct when designing a release or contribution policy so a familiar badge does not become a substitute for evidence it cannot provide.

Choose a supported signing and verification setup

Git supports signing through configured mechanisms, and GitHub documents GPG, SSH, and S/MIME verification behavior. Availability depends on installed Git, cryptographic tools, key setup, and platform rules. SSH signing support in Git requires an appropriate modern version, commonly documented from Git 2.34, and verification needs an allowed-signers trust configuration. Do not infer a complete setup from a single signing flag. Protect private keys, define ownership and rotation, and use synthetic disposable keys only in separately authorized labs. This course does not generate, import, upload, or use real signing credentials.

Inspect signature status without inventing trust

Git log can display signature status using pretty-format placeholders. In the isolated unsigned lab, %G? reports N for no signature. Other states depend on verifier setup and key trust, so do not map every non-N symbol to approved identity. git verify-commit performs cryptographic verification through the configured mechanism and can fail because a commit is unsigned, the signature is invalid, or verification prerequisites are absent. Read diagnostics carefully. These commands inspect existing data; they do not sign it, upload keys, or grant access to a hosted repository.

bash Inspect an unsigned synthetic lab commit

git log -1 --format=%G?
git log -1 --format=fuller

With signing disabled in the isolated validation environment, the first command prints N. The fuller view shows metadata, not authenticated account ownership. Verification of an actual signed object requires a separately configured trusted verifier and is not claimed by this lab.

Evaluate verified facts under an explicit policy

A policy can require cryptographic validity, an approved signer, expected artifact or commit identity, and review evidence. The pure function below consumes pre-verified facts; it is not a signature verifier and must not accept arbitrary booleans from an untrusted branch as proof. Keep the verification tool, trust roots, and policy version recorded with decisions. A platform’s persisted verification display may have documented behavior across key changes, so consult current official rules rather than assuming every badge is a live reevaluation of key revocation. Local verification and hosted display can have different contexts.

python A teaching policy over already verified facts

def eligible_signed_change(facts):
    return (
        facts.get("signature_valid") is True
        and facts.get("signer_approved") is True
        and facts.get("commit_identity_matched") is True
        and facts.get("review_current") is True
    )

assert not eligible_signed_change({"signature_valid": True})

This local Python example performs no cryptography or external access. A real implementation obtains facts through trusted verification and binds them to the exact candidate. Passing this policy does not imply all security or functional requirements are satisfied.

Plan key loss, compromise, and history changes

A signing policy needs recovery for lost keys, response to compromise, approved identity changes, and a way to verify historical releases. Rewriting a signed commit creates a different object; an existing signature does not automatically transfer to it. Merge and squash workflows can change which objects and identities appear on the destination, so verify the repository’s documented platform behavior. Keep private keys out of repository files, logs, and CI artifacts. If credentials are exposed, follow the owner’s response instead of merely removing one file. Practice policy evaluation using synthetic facts and unsigned local objects without claiming a cryptographic test that was never performed.

Common errors and fixes

Verified is treated as code-quality approval

Why it happens: Identity evidence is confused with behavior and review.
How to fix it: Require separate tests, review, and authorization evidence.
Prevent it next time: Document the precise signature claim.

A signature fails on another machine

Why it happens: Verifier tools or trust configuration differ.
How to fix it: Inspect diagnostics and establish the approved verification context.
Prevent it next time: Version verification assumptions and trust roots.

A rebased commit is assumed to keep its old signature

Why it happens: The new object is mistaken for the original.
How to fix it: Verify the resulting object under policy.
Prevent it next time: Review signing implications before history rewriting.

Check your understanding

1. A valid signature comes from an unknown key. Is the change approved?

Show worked solution

Cryptographic validity alone does not establish an approved signer or review. Apply the trust policy and verify candidate identity, authorization, and required evidence separately. Do not equate possession of any signing key with project authority.

2. Why might local verification and GitHub’s displayed status differ?