Trust is Good, Control is Better - Why you should Sign your Git Commits
Dominik Stecher
May 20, 2025
Trust is a cornerstone of modern software development - especially in open-source projects and for distributed teams. We rely on Git to track who contributed what and when. But here's something most developers don't realize:
Git, per default, does not verify commit authorship. At all.
And worse: GitHub visually reinforces false author information, creating a false sense of authenticity. Let's unpack that.
Anyone can fake a Commit Author - And it looks real on GitHub
Git allows you to define the name and email address used for your commits locally. This means anyone can change their identity by changing their local git config as follows:
# How to impersonate Linus Torvalds
git config user.name "Linus Torvalds"
git config user.email "torvalds@linux-foundation.org"
A commit that was apparently issued by the real Linus Torvalds, with a link to his real profile. Keep in mind that is his user is not a registered contributor in the private repo.
Now every commit will appear to be from Linus Torvalds himself - and if that email address is connected to a GitHub account, GitHub will display the user's profile picture, name and even link to their GitHub profile as if they made the commit themselves - without notifying them about it of course.
There is no default verification of a committer's identity.
This applies to any Git commit in any repo - even in private repositories, where such impersonation can be especially misleading. For example, you can create a fake commit that appears to be from someone who does not have accress to the repository, like Linus Torvalds in our hypothetical example. This can confuse reviewers, managers and automated tools alike.
Likewise, faking a commit in the name of a co-worker can of course also cause a major trust problem and pose a problem not only for a project or product, but also for the development team.
When clicking on a commit, an impersonated user (e.g. Linus Torvalds) even appears to have their own commit history.
How (and Why) It Works
Impersonation in Git is not a bug - it's a feature of how Git is designed. Thanks to its decentralized architecture, every clone of a repository is a full copy, including its entire history and configuration. Any changes made to the local Git configuration (like author name or email) only affect your local copy. Git itself does not verify the identity of commit authors by default - not even when pushing those commits to a remote.
Authentication only becomes relevant when pushing changes to a remote repository, such as GitHub. But even then, GitHub verifies who is pushing - not who authored the commits. There are no cross-checks to ensure the name and email in the commit metadata match the identity of the authenticated user. Whether you authenticate via HTTPS or SSH doesn't matter - as long as you have valid credentials while pushing, you're good to go as any individual.
The output of the git log command, publicly showing all information an impersonator needs in the "Author" field.
At the same time, GItHub makes impersonation even easier than you'd think. All the necessary information to impersonate someone is already stored in the Git history. You don't have to guess Linus Torvalds's email address to make it appear like he authored your commit. You can just clone any of his public repositories and run git log - his GitHub profile's name and email are right there, ready to use.
It gets worse: Commit History can be manipulated too
Beyond impersonation, someone with write access can:
- Delete code
- Insert malicious code disguised as someone else
- Fabricate a contribution history
- Rewrite commit history (in non-protected branches) for destructive or misleading purposes
Even though Git is technically append-only, in practice, with force-pushes or merges, chaos is easy to create - and hard to detect without deep auditing.
While this isn't necessarily a direct security threat in Git itself, it's a huge trust and integrity issue.
Signed Commits: The only real Proof of Authorship
A signed commit on GitHub showing the green "Verified" badge.
Git support commit signing cia GPG, SSH or S/MIME. A signed commit contains a cryptographic signature that:
- Proves the commit came from a user with access to a private key
- Can be verified using the public key on GitHub (this can even be your authentication key, if additionally added as signing key)
- Cannot be altered without invalidating the signature
GitHub visually marks signed commits with a green verified badge - but only if the signature matches a public key uploaded to the author's GitHub account.
This is the only reliable way to prove a commit truly came from someone.
How to Sign Commits - A Brief Overview
GitHub's documentation has a nice explanation for signing commits. For example, to sign your commits using an SSH key, you only have to add your public key to your account settings in the SSH and GPG keys section - just make sure to add it as a signing key by importing it a second time. Then, in your terminal type:
# How to sign your commits using an SSH key
git config [--global] gpg.format ssh
git config [--global] user.signingkey /PATH/TO/.SSH/KEY.PUB
git config [--global] commit.gpgsign true
Note: signingkey here points to the public key, however, Git automatically uses the private key for signing. The --global option can be omitted if you want to apply this for one repository only, just make sure to change your working directory to the corresponding .git directory first.
GitHub isn't loud enough about this
While GitHub supports commit verification and offers branch protection rules, the platform does little to educate users about why commit signing matters - or how easily Git metadata can be forged.
There are:
- No strong nudges to use signing
- No warnings when you commit or merge unsigned contributions
- Very few default protections enabled in new repositories
Instead, GitHub only rarely describes such impersonation options in its documentation too. For example, this page about setting up your account only briefly mentions the option to (freely) "set the email address that is used to author commits on GitHub and on your computer". This silence can be dangerous. Especially in private repositories, where small teams often assume they know every contributor, the appearance of a legitimate user's commit can be deeply misleading - even if that user never had access.
What you should do: Enforce Signed Commits
If you maintain a serious repository, whether open or private, you should enable signed commit enforcement on your main branch.
Here's how:
- Go to your repository's Settings > Branches
- Create or edit a branch protection rule (e.g., for
main) - Set it to "Active" and select target branches
- Enable "Require signed commits"
- Click on "Create"
All collaborators will now be required to sign their commits. A small adjustment with a huge trust benefit.
Note: This option is only available for public repositories free of charge. For private repositories, you need to move to a GitHub Team organization account.
Optional: GitHub's Vigilant Mode - But you have to ask for it
Interestingly, GitHub does offer a personal protection mechanism against identity spoofing - it's called Vigilant Mode. But here's the catch:
It's completely optional. And it's off by default.
An example SSH and GPG key settings page with activated Vigilant Mode.
When you enable Vigilant Mode, GitHub will mark all unsigned commits associated with your account as "Unverified", even if they have your name and email. This prevents your profile from being falsely "attached" to unsigned commits made by someone else using your public email. This way, you regain some control over how your identity is visually attached to commits.
However, this still does not prevent fake commits! It only makes it easier to identify them visually on GitHub. It also does not enforce signing, which still has to be done via your local Git config and/or branch protection settings.
How to enable Vigilant Mode:
- Go to GitHub > Settings > SSH and GPG keys
- Scroll down to "Vigilant Mode" and enable it
It takes a tiny bit of work and it one of the few ways to protect your public identity on GitHub without needing repository-level control.
Final thoughts: Trust shouldn't be optional
It takes ten seconds to fake a commit author. It takes a few minutes only to start signing your commits. One earns you a green checkmark. The other could cost you your reputation - or worse.
Until GitHub makes this more visible, it's on us to educate and protect ourselves.