Git SSH Signatures Verify Identity Only Within a Trust File

A signed commit proves that some key produced a signature over the commit object. It does not, by itself, prove that the key belongs to the person named in the commit metadata. Git's SSH signing support makes this distinction visible through gpg.ssh.allowedSignersFile. A signature can be cryptographically valid while its trust level remains undefined because the public key is absent from the allowed signers file.

That distinction matters in automated review and release workflows. A verifier that checks only whether a signature exists may accept a key that was never authorized for the repository or organization. A verifier that checks the allowed signers mapping can associate a principal with a public key, but it still depends on the correctness and freshness of that file.

Signing is not authorization

The signing key identifies a cryptographic actor. Repository permissions decide what that actor may change. A signed commit can still contain malicious code, and a compromised development account can sign a change with an authorized key. The signature helps establish provenance and detects some forms of object tampering. It does not replace review, branch protection, scoped tokens, or a clean build.

Git's documentation also notes that verification tracks the signer identity in the signature. Organizations should decide which identity is trusted for which purpose. An SSH key used for developer commits may be different from a release key or an automation key. Mapping those keys to broad wildcard patterns can erase the separation that the trusted signer file was intended to provide.

Operate the trust file as code

Store the allowed signers material in a reviewed repository or managed configuration, with an explicit owner and rotation process. Keep a one-to-one mapping where practical. Remove keys when people leave, when devices are lost, or when an automation identity is retired. Review changes to the file with the same care as a production change, because adding a key grants signature trust.

In CI, run git verify-commit or git verify-tag and require a successful trust result, not only a parseable signature. Pin the verifier's Git version and capture its output in the build record. Reject signatures with unknown trust. If the repository stores its own allowed signers file, protect the branch that changes it and consider how a malicious commit could alter both the signer list and the verification workflow in the same change.

Test both failure modes

Use two test cases. First, verify a commit signed by an approved key and confirm that the expected principal is reported. Second, verify a valid signature from a key not in the trust file and confirm that the workflow rejects it. Add a case for a deleted or expired identity. These checks catch the common mistake of confusing signature validity with authorization.

The limit remains: signed history is useful evidence, not a statement that the code is safe. A strong program connects signing to protected branches, independent review, reproducible builds, and artifact provenance. Git provides the cryptographic primitive. The organization still has to define who is trusted and what a trusted signature allows.

References

• Git project, git-config: gpg.ssh.allowedSignersFile
• Git project, git-verify-commit