---
title: "GitHub Co-Founder Says Git 3.0’s Switch to SHA-256 Is a Costly Mistake"
description: "Scott Chacon says the security gain is theoretical while developers and hosting services face years of expensive migration"
author: "rews desk"
published: 2026-10-01T09:10:00Z
modified: 2026-10-02T05:22:38Z
url: https://rews.cc/a/github-co-founder-says-git-3-0-s-switch-to-sha-256-is-a-cost-10aca3
language: en
tags: ["git", "sha-1", "security", "open-source", "hashing", "tech"]
publisher: "Rews (https://rews.cc)"
---

# GitHub Co-Founder Says Git 3.0’s Switch to SHA-256 Is a Costly Mistake

*Scott Chacon says the security gain is theoretical while developers and hosting services face years of expensive migration*

By rews desk · October 1, 2026 · https://rews.cc/a/github-co-founder-says-git-3-0-s-switch-to-sha-256-is-a-cost-10aca3

## In brief

- Git 3.0 will switch the version control system’s default hashing algorithm from SHA-1 to SHA-256
- GitHub co-founder Scott Chacon called the change a costly global migration with little practical security benefit
- He argued that Git is effectively immune to second-preimage attacks and that real compromises come via compromised npm packages
- Hacker News commenters disputed him, citing the practical 2017 SHAttered proof of concept and his imagined GitHub interface
- One commenter suggested the move is driven by compliance rules in organizations where SHA-1 is banned outright

The next major release of Git will replace SHA-1, the hashing algorithm at its core for 20 years, with the stronger SHA-256 — a change that a co-founder of GitHub says will impose enormous costs around the world for almost no practical benefit.

Scott Chacon, [a co-founder of GitHub](https://gitbutler.ghost.io/author/scott/) and the author of the manual *Pro Git*, laid out his case on Thursday in a blog post at GitButler, the version-control company he now runs. The change, he wrote, is “about to cost everyone a lot of time and angst for little benefit,” and “virtually nobody knows what’s coming.” He called it “a huge, costly, global train wreck of a change for almost no practical value.”

Git is a content-addressable database. Files, trees and commits are stored under the hash of their contents, so identical content is never stored twice, and each commit encodes the hash of the one before it, chaining integrity through the whole history. That chain is what gives a repository “cryptographic integrity,” Mr. Chacon wrote.

Git has run on SHA-1 since Linus Torvalds picked it in 2005, and it has worked well, he wrote. To his knowledge, amid the billions of repositories Git has accumulated, two different files have never once accidentally produced the same hash. The math supports that: with SHA-1’s 160-bit output, a single project would need about 1.4 septillion random files before a chance collision became likely.

The case for switching rests on two published attacks, the SHAttered proof of concept in 2017 and a 2020 paper titled “SHA-1 is a Shambles.” Together they showed that deliberate collisions are now manufacturable for some content shapes, given modern GPU farms and what Mr. Chacon put at a few tens of thousands of dollars. In the cryptographer’s sense, SHA-1 is “broken”: the collisions are no longer impossible.

Mr. Chacon separated two kinds of attacks. In a collision attack, the attacker authors both files, one benign and one malicious but hash-identical, hands out the benign one and swaps it later, possibly beneath a signed tag. In a second-preimage attack, someone builds a malicious file matching the hash of an existing file written by somebody else. The second kind is scarier, he wrote, and Git is effectively immune: even running the fully broken MD5 algorithm, an attacker would need every one of Earth’s roughly 3 billion GPUs, each upgraded to a top-end card, churning for about 16 billion years, roughly the age of the universe.

Assume that is trivial, he wrote, and the attacker still must get strangers to fetch the doctored file and run it usefully. Those questions rarely enter the debate.

Trust in software “is based on ‘where do you pull from?’ and it always has been,” Mr. Chacon wrote, a point he said Mr. Torvalds made at Git’s creation. Real attacks look nothing like a GPU farm, he argued: more often, someone socially engineers control of an npm package, and millions of projects pull the poison automatically, file by file. That, he wrote, is “maybe a billion times simpler, cheaper and more likely to succeed”

The post drew quick pushback on Hacker News. “This article is full of mistakes and misleading claims,” one commenter, kpcyrd, wrote, arguing that SHAttered “was specifically a pratical proof of concept,” that Git escaped harm in 2017 only because the researchers “didn’t bother bruteforcing a git-blob prefix” and that the essay wrongly treats collision attacks as harmless.

Another commenter, plorkyeran, said the essay leans on an invention: GitHub does not support SHA-256 repositories at all, so the post imagined an especially clumsy way to add support and then declared the problem unsolvable. “Selecting the repository format based on the first thing pushed to it is really not a crazy idea,” the commenter wrote, while conceding that the submodule problem Mr. Chacon raised is real.

A third, gandreani, offered a counterexample: Fossil, the SQLite project’s own version control system, added SHA3-256 “on 2017-03-01 (six days after the SHAttered attack was first published)” and has since made it the default for new repositories.

One commenter, 0x00cl, doubted that security motivated the change at all, guessing instead at certification rules that bar governments and companies from running software built on SHA-1. As evidence, the commenter quoted what it said was a Git mailing-list discussion of the 3.0 changes: “There are organizations where SHA-1 is blanket banned across the board - regardless of its use.”