GitButler post calls Git 3.0's SHA-256 default a costly change with little payoff

Git 3.0 is set to change the default hashing algorithm used for object storage from SHA-1 to SHA-256, and a blog post published on GitButler's site — currently sitting on the Hacker News front page — argues the switch is a globally expensive disruption that delivers almost no practical security benefit, and that most developers are unaware it is coming.

How Git uses hashes

Git is a content-addressable database: it computes a hash of every file, tree and commit and uses that hash as the key into a key/value store. Identical content is stored only once, and because each commit records the hash of its parent, any alteration to historical content changes every hash that follows it. Hashing the tip commit effectively fingerprints an entire project history.

That hash function has been SHA-1 since Linus Torvalds chose it when Git was created in 2005. According to the GitButler post, no accidental collision has ever been recorded across the billions of objects in every Git repository ever made, and the birthday bound on SHA-1's 160-bit output means a single project would need roughly 1.4 septillion random files before an accidental collision became plausible.

What "broken" means here

The move toward SHA-256 follows published collision attacks — SHAttered in 2017 and SHA-1 is a Shambles in 2020 — which put purpose-built collisions within reach of modern GPU farms for an estimated few tens of thousands of dollars. In cryptographic terms, "broken" means collisions can be manufactured on purpose for certain content shapes, not that two reasonable files will ever collide by accident.

The post draws a sharp line between collision attacks and second-preimage attacks. A collision requires the attacker to author both a benign file and a malicious twin in advance, then swap them once the benign version has gained trust. A second preimage — crafting a malicious file to match the hash of a file someone else wrote — would be far more dangerous, but as the author points out, essentially no widely used hash function, including the thoroughly broken MD5, is practically susceptible to it. Any realistic attack on Git therefore requires the attacker to be the original author of the content.

Trust comes from distribution, not hashes

The core of the argument is that hashing was never the foundation of trust in source control. The post quotes Torvalds from 2005: "I really think people should not consider the sha1 the 'security'. The real security is in distribution." Developers trust a repository because of where they pull from, not because of the strength of its object hashes.

Even in an unrealistically generous scenario where second preimages were cheap to produce, the author argues, an attacker would still face the problem of getting the malicious file fetched and executed by people who do not know them — practical hurdles that the post says are largely missing from the conversation around this migration. Malicious files do regularly make their way into codebases, the post acknowledges, but not because anyone burned a fortune on GPU time to manufacture matching checksums.

The author concedes that the SHA-256 transition is the product of years of effort by capable people, but predicts it will consume enormous amounts of the ecosystem's time for gains that remain essentially theoretical.

Why it matters

If SHA-256 becomes the default in Git 3.0, the resulting migration work will not be confined to Git's maintainers. Repositories, hosting platforms and tooling that were built on SHA-1 assumptions will all be touched, and the GitButler post warns that the cost in time and disruption will fall on the entire community while almost nobody sees the change coming.

The piece also reframes a broader debate for the industry: if trust in code ultimately derives from distribution channels and review rather than hash strength, then resources spent hardening the hash function may address the wrong layer of the supply chain. Teams that depend heavily on Git should watch the Git 3.0 release plans closely, decide what the hash transition means for their own tooling, and weigh in while the change can still be shaped.