Why Verified Commits Matter in Git — And How I Fixed Mine with SSH Signing
When I first started using Git, I had no idea that anyone could easily impersonate me — or anyone else — in the commit history. It turns out it’s shockingly simple. All you need to do is run a couple of commands like:
git config user.name "Someone Important"
git config user.email "
"Suddenly, your commits appear as if they came from that person. The commit message, author field, and history all reflect the fake identity. No hacking required. This isn’t just a theoretical issue. Many supply chain attacks rely on exactly this technique: an attacker creates a convincing pull request under a trusted name, gets it merged, and malicious code slips into the project. Without verified commits, there’s no cryptographic proof that the person who pushed the code is really who they claim to be.
That’s why verified commits are a critical security practice. Whether you’re running your own GitLab instance, using GitHub, or managing any shared repository, you should strongly consider requiring verified commits — either through automatic enforcement (if your platform supports it) or rigorous peer review.
My First Step: Switching to GPG Signing
Once I understood the risk, I created a GPG key, uploaded the public key to my GitLab account (with a verified email address), and enabled commit signing. From that point on, my commits showed up with a nice “Verified” badge. It felt secure and professional.
The Keycloak Integration That Broke Everything
Earlier this year, I connected my self-hosted GitLab instance to Keycloak to centralize authentication across all my applications. The move was mostly smooth and improved my overall security posture. But then something strange happened: all my new commits suddenly appeared as “Unverified.” I spent nearly two full days troubleshooting — checking keys, emails, configurations, and even re-uploading keys — with no success. The problem felt impossible to pinpoint.
The Simpler Solution: SSH Commit Signing
Yesterday I finally dug deeper and discovered that modern Git supports two main ways to sign commits: GPG keys and SSH keys.
Since I already use SSH keys to authenticate and push to GitLab, switching to SSH signing was straightforward. Here’s exactly what I did:
- Tell Git to use SSH for signing:
git config --global gpg.format ssh- Point Git to my existing SSH public key:Bash
git config --global user.signingkey ~/.ssh/id_ed25519.pub(Replace with the path to your own public key file.)
I already had these settings enabled for automatic signing:
git config --global commit.gpgsign true
git config --global tag.gpgsign trueThat’s it.
Because my SSH public key was already uploaded to my GitLab account (required for SSH access anyway), and the key supports both authentication and signing (the default for most modern keys), all my commits immediately started showing as Verified again.
Why SSH Signing Feels Easier Than GPG
- No need to upload the public key to external GPG keyservers.
- You’re probably already using an SSH key for Git operations. It is much more convenient than using credentials via https.
- The configuration is lightweight and integrates cleanly with your existing setup.
- GitLab and GitHub both support SSH commit verification out of the box.
The Bigger Picture: Make Verified Commits Non-Negotiable
Verified commits close a dangerous gap in the supply chain. They provide cryptographic proof that the code came from the claimed author and hasn’t been tampered with after signing.
If you administer repositories or run a Git instance:
- Enable “Reject unsigned commits” push rules where available (i.e. Gitlab Premium and Ultimate tiers).
- On GitHub, use branch protection rules to require signed commits.
- Encourage (or require) your team to sign every commit.
It only takes a few minutes to set up, but it adds a meaningful layer of protection against impersonation and supply chain attacks. In my case, switching to SSH signing restored my verified status in minutes and reminded me how important this practice really is. My Git workflow now feels secure again — and the world (or at least my private cloud) is a little safer.
Have you started signing your commits yet? Are you using GPG, SSH, or both? I’d love to hear what worked best for you in the comments.
Why Verified Commits Matter – Visualized
To make the process easier to understand, here’s a clear flowchart of the Git Commit Verification Flow. It shows how easy it is to impersonate someone without signing, and how cryptographic signing (especially with SSH keys) creates a trustworthy, verifiable chain.
How to Read the Diagram
-
Right side (Insecure path): Anyone can fake an author identity with just two git config commands. The commit looks legitimate to the naked eye, but carries no proof of who really created it. This is the vector many supply chain attacks exploit.
-
Left side (Secure path): When you enable commit signing:
- Git uses your private key (GPG or SSH) to create a cryptographic signature.
- You upload the public key once to your Git hosting platform (GitHub, GitLab, etc.).
- The platform automatically verifies the signature on every push.
- Successful verification results in the trusted “Verified” badge.
SSH signing (as described in the post) makes this especially convenient because most developers already have an SSH key set up for pushing code. After setting gpg.format=ssh and user.signingkey, everything happens automatically with commit.gpgsign=true.
Quick Setup Reminder for SSH Signing
Add these lines to your global Git config:
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub # or your key path
git config --global commit.gpgsign true
git config --global tag.gpgsign trueDid you find this post helpful? You can support me.
Author Profile
Latest entries
blog26.03.2026Git – Verified Commits with SSH keys
blog25.03.2026Kubernetes – Adventures – Argo-CD- blog19.03.2026Kubernetes – Adventures – Pilot
blog15.03.2026ConfDroid Puppet Modules – NRPE
