Signed Git Commits — What “Verified” Actually Means
Signed Git Commits — What “Verified” Actually Means
A commit on a hosting platform may carry a reassuring “Verified” label. It is natural to read that label as “this change came from the person named here, was reviewed, and is safe to use.” That interpretation is much larger than what a digital signature can establish.
A signed Git commit is useful, but its usefulness is specific. It can let a verifier check that a cryptographic key produced a signature for a particular commit, according to the rules of Git and the hosting platform. It does not, by itself, tell us whether the change is good, whether the key was controlled by the expected person at the time, or whether the resulting software was built safely.
What a Signed Commit Connects
Git records a commit as an object containing information such as the tree being recorded, its parent commit or commits, author and committer metadata, and the commit message. A signature is attached to that commit. During verification, Git uses the relevant public key to check whether the signature matches the signed data.
That gives us a valuable statement about integrity: the signed data has not changed in a way that would make the signature invalid. It also gives us a key identity to investigate. The important word is investigate. A name or email address displayed next to a key is metadata and policy input, not an independent proof that a particular human intended this exact change.
This is similar to checking a seal on an envelope. A seal can show that the envelope was opened or altered after it was sealed. It does not tell us whether the contents are correct, whether the person who sealed it had authority, or whether the instructions inside are wise.
How Git Signs and Inspects Commits
Git’s documentation describes signing commits and tags with a configured signing key. An individual commit can be requested with -S:
git commit -S -m "Describe the change"
The exact key and signing program depend on the local configuration. Git’s configuration reference documents settings such as the signing format and the key selected for signing. A project can also request signing by default with a setting such as:
git config commit.gpgsign true
That setting changes the default behavior for commits in the relevant configuration scope. It does not establish a trust policy for every key in the repository, and it does not make an unsigned historical commit retroactively signed.
Git can show signature information while displaying history. The official Git book documents git log --show-signature and the %G? pretty-format placeholder for inspecting signature status. A verifier should treat the result as one input to a decision, not as a complete security review.
What a Hosting Platform Adds
A hosting platform can associate a public key with an account, check whether the email address is allowed for that account, and display a status such as “Verified.” GitHub documents three signing families for commits: GPG, SSH, and S/MIME. Its interface also lets a reader inspect more detail behind the status label.
This platform-level policy is useful because a raw signature normally does not arrive with all of the context a reader needs. Which account is allowed to use the key? Is the email address verified? Is the key still accepted? How does the platform handle a revoked or removed key? Those questions belong to the verifier and the service’s policy, not to Git’s object format alone.
There is also a practical difference between “the signature is mathematically valid” and “this host currently recognizes it.” A local Git installation may have the public key and validate the signature while a hosting service has no matching account policy. Conversely, a platform badge reflects that platform’s current verification rules; it is not a universal certificate from every person who might consume the repository.
What “Verified” Does Not Prove
A valid signature is not a code review. The signed commit may contain a bug, an unsafe default, a dependency with a vulnerability, or a change that simply does not meet the project’s requirements. Review status must come from a review process, protected branches, tests, and the project’s own acceptance rules.
It is also not proof that the displayed person personally wrote every line. Git has separate author and committer fields, and workflows may involve rebases, cherry-picks, automation, or maintainers applying someone else’s patch. A signature can show that a key signed a commit; interpreting that fact as personal authorship requires additional context.
Nor does a signature prove that the key was not compromised. If an attacker obtains access to a private key, they may be able to create valid signatures until the compromise is detected and the key is replaced or revoked. Key custody, recovery, rotation, and account controls remain important.
Finally, a commit signature does not prove how a release artifact was produced. A package may be built from a different commit, with different dependencies, on an untrusted or poorly controlled build system. The path from source to artifact needs its own evidence.
Three Controls That Are Easy to Confuse
Commit signature
This answers a narrow question: can the signature on this commit be validated with the public key, and does that key satisfy the verifier’s trust policy? It helps protect the connection between a key and a particular Git object.
Developer sign-off
The Linux kernel’s contribution documentation describes a Signed-off-by: line as a certification that the contributor created the work, had the right to submit it, or received it under the stated conditions. That is a project-process statement. It is not the same mechanism as a cryptographic commit signature, even though both use the word “signed.”
Build provenance
SLSA describes provenance as information about how an artifact was produced. Its requirements discuss properties such as provenance authenticity, the identity of a build platform, and isolation between builds. That is a different boundary from the source commit. A trustworthy release process may connect a reviewed source revision to a specific artifact, but a commit signature alone does not create that connection.
A Proportionate Workflow for a Small Project
A small project does not need to imitate the controls of a large software distributor all at once. It can start by making the questions explicit:
- Identify which keys and accounts are expected to sign changes.
- Check the signature status and the key identity rather than relying only on a badge.
- Review the actual diff, tests, dependency changes, and release notes.
- Protect important branches so that a signature is not the only control around merging.
- For releases, record which source revision produced the artifact and where the build ran.
- Plan what happens when a key is lost, compromised, or replaced.
These steps are deliberately less glamorous than a green label. They also answer more useful questions. Who was authorized to make this change? What exactly changed? Was it reviewed? Can we connect the file users download to the source that was inspected? A signature supports some of these questions, but it cannot answer all of them.
Conclusion
Signed Git commits are best understood as evidence, not a verdict. They can strengthen the integrity and traceability of a source history when the key and verification policy are handled carefully. They cannot replace code review, dependency analysis, account security, branch protection, or build provenance.
The next time a commit says “Verified,” the useful response is neither blind trust nor complete dismissal. Ask what was verified, by whom, against which key, and what remains outside that statement. Security gets clearer when a small label is not asked to carry the weight of an entire process.