GitHub co-founder Scott Chacon: Git 3.0's SHA-256 default will be a costly mistake

GitHub and GitButler co-founder Scott Chacon argues in a new blog post that Git 3.0's planned switch of the default content hash from SHA-1 to SHA-256 will be a costly mistake: an expensive global migration with little practical security benefit.

The post is an argument, not an announcement; few know it is coming.

Why Git 3.0 is moving to SHA-256

Git is a content-addressed database: every file, tree and commit is stored under a hash of its contents, and each commit encodes its parent's hash, chaining the history together. Git has used SHA-1 since Linus Torvalds chose it in 2005.

SHA-1 is now considered semi-broken: the SHAttered (2017) and SHA-1 is a Shambles (2020) papers showed that manufactured collisions are possible, though none have been exploited in practice. Git 3.0 therefore plans to default to SHA-256, a breaking change listed for the release.

The case against the migration

Chacon's core argument: trust in version control does not rest on the hash. He quotes Linus Torvalds: "I really think people should not consider the sha1 the 'security'. The real security is in distribution." Real supply-chain compromises, he writes, come from compromised maintainers and registries, not hash collisions.

The costs are broad: new repositories will default to SHA-256 while existing ones stay SHA-1, the formats cannot be mixed, and submodules must match their parent's. Converting a project rewrites every object and breaks signatures, old links and tooling expecting 40-character hashes; many libraries have only partial support.

An alternative: independent tree hash headers

Rather than migrate the ecosystem, Chacon proposes "independent tree hash headers": when signing a commit or tag, compute a second hash (SHA-256, BLAKE3 and so on) over the tree contents and inject it into the signed object, so the signature covers both the SHA-1 history and the independent hash. An attack would then require a collision in both algorithms, which he argues is more secure than SHA-256 alone.

A precedent: Colin Walters' git-evtag has added a Git-EVTag-v0-SHA512 tree checksum to signed tags since 2015. In Chacon's proof of concept, the 35 GB, 2.1-million-file Chromium tree took 5 seconds on an M5 Mac.

The post asks the community to reconsider before Git 3.0 ships: the migration could take years, Chacon warns, and a future SHA-256 weakness would leave the ecosystem in the same spot.