New research shows a signed Git commit's hash isn't unique as assumed. Someone without the signing key can create a second commit with same files, author, date, and valid signature, yet GitHub still stamps "Verified." Everything matches except the hash, and that matters.
You trust that little green "Verified" badge on GitHub, right? It's supposed to mean a commit is authentic, signed by someone with the right key. But new research just dropped a bombshell: that trust might be misplaced. A signed Git commit's hash isn't the unique fingerprint the software world assumes it to be. In fact, someone without the signing key can create a second commit with the same files, author, and date, and it still gets stamped "Verified." Everything a reviewer would check looks identical. The only difference? The hash. And that matters more than you'd think.
### What Exactly Is a Git Commit Hash?
Every Git commit gets a SHA-1 hash, a 40-character string that's supposed to be unique. Think of it like a digital fingerprint. It's generated from the commit's content, author, date, and parent commits. The whole security model of Git relies on this hash being one-of-a-kind. If you change even one byte, the hash changes. That's why signed commits are trusted: they prove the hash hasn't been tampered with. But this research shows that's not entirely true.
### The Flaw: How Commits Can Be Rewritten
The researchers found a way to generate a second commit with the exact same content, author, and timestamp, but a different hash. And since the signature is tied to the content, not the hash, the signature remains valid. GitHub's "Verified" badge just checks that the signature matches the content, so it lights up green. The new hash doesn't break anything because the signature still verifies the data is intact. But here's the kicker: the hash is the commit's name. If two different commits have the same data but different names, which one is the real one?
### Why This Matters for Developers
- **Supply chain attacks:** An attacker could create a malicious commit with a different hash, tricking automated tools that rely on hashes for integrity checks.
- **Audit trails break:** If you're tracking changes by hash, a rewritten commit could slip through unnoticed.
- **Trust erosion:** The "Verified" badge loses its meaning if it doesn't guarantee a unique, untampered commit.
This isn't just a theoretical issue. The researchers demonstrated it with real signed commits on GitHub. The platform still shows "Verified" even when the hash is different. That's a problem for anyone relying on Git for security.
### What Can You Do About It?
For now, the fix isn't in your hands. Git and GitHub need to address this at the protocol level. But you can stay aware. Don't rely solely on the "Verified" badge. Check commit hashes manually when possible, especially for critical code. Use additional verification tools that look beyond the signature. And keep an eye on updates from Git and GitHub about this vulnerability.
### The Bigger Picture
This research highlights a fundamental flaw in how we trust digital signatures. It's a reminder that even the most trusted systems have edge cases. The software world treats Git hashes as sacred, but they're not as immutable as we thought. For now, the best defense is awareness. Don't assume "Verified" means unchangeable. Dig deeper, verify hashes, and stay skeptical.
In a world where code integrity is everything, this is a wake-up call. The hash is not the commit. It's just a name. And names can be rewritten.
