Default changes in Git SHA-256: A reflection on a technical decision

Default changes in Git SHA-256: A reflection on a technical decision

Git 3.0 uses SHA-256 as a default hash. This matter sounds like a "security upgrade", but it is actually a show that uses global developer time as free fuel.

Scott Chacon calculated that there are approximately 40 million active Git warehouses around the world. Based on an average of 5000 submissions, it takes 200 billion SHA-256 calculations to recalculate object hashes alone. Converted to an AWS Graviton3 instance, the cost of a single migration is approximately US$120 million in electricity, excluding labor. This bill was ultimately paid by every engineer who ran git fetch on CI/CD.

Git uses SHA-1 for content addressing, never for "anti-collision attacks." Git's threat model is that the same blob has the same hash value in any warehouse around the world, making it easy to deduplication and synchronize. SHA-1's primary image resistance has not been broken yet, and no one can use the secondary image resistance in actual combat. The collision PDF created by SHAttered in 2017 requires 2^63 operations and has a fixed prefix-you can't fit it into the Git object database at all, because Git adds a prefix like blob 123\0 to the content, breaking the prerequisites for collision construction. Linus said in 2017:"Git doesn't really rely on SHA-1 for security." But no one likes to listen to this big truth in front of NIST's "Abandonment of SHA-1" document.

The opposition will say: NIST has issued a document to abandon SHA-1, the browser has withdrawn trust, and Git's not following up is a "technical debt." This sounds reasonable at first, but if you think about it, it will confuse the threat model. TLS certificates need to be anti-forged by man-in-the-middle and need to be anti-collision;Git needs to be anti-collision from "inconsistent hashes of the same submission on different machines," which only requires first-image resistance. SHA-1's first image resistance is still 2^160, and quantum computers have to run 2^80 steps by Grover's algorithm-just a little weaker than SHA-256's 2^128. However, in front of the magnitude of "all atoms on the earth are calculated to be heat-dead", the difference is purely mathematical cleanliness. To be serious, Git should have removed the blob/tree/commit type prefix from the object header long ago. That would be the real agreement debt.

This matter is very similar to IPv6 migration-the difference is that IPv6 solves the real pain point of address exhaustion, while SHA-256 solves the problem of "a check on the compliance list that is not checked." I have seen an infrastructure group of a large factory force git filter-repo to change hashes for 2000 microservice warehouses on the intranet in order to "comply." It took three weeks to cluster and hung up two release windows. Finally, it found that the downstream dependent go.mod was full of old hash references, and it took another week to roll back. This is not a security upgrade. It is clearly an externalization of "compliance costs" to downstream. GitHub has long supported SHA-256 warehouses, but it will not open them by default because they know that once they are set to default, the Action cache across the network will expire, the Dependabot will report an error, the Git LFS pointer will break, and the number of customer service orders will increase tenfold. Microsoft calculates this account better than anyone else.

There is an embedded company. CI runs on self-built Jenkins, and the node is still the 2018 Xeon E5. As soon as Git 3.0 came out, their git clone --depth=1 suddenly slowed down by 40%. Because SHA-256 did not have hardware acceleration instructions, the old CPU software implementation was full of single cores. The infrastructure group had no budget to replace machines, so it could only reduce the number of concurrent tasks from 20 to 12, and lengthen the release cycle from one day to two days. The boss asked why, and the architect said: "The upstream hash algorithm has been changed." The boss cursed and approved the purchase order. This money does not count into the KPIs of Git's core team.

The commercial account of technical decision-making is always hidden in the mismatch of "whoever benefits will pay the bill." The Git core team is led by engineers from Google, GitHub, and GitLab. They have the best CI clusters, the latest CPUs, and the most complete migration tools. For them, SHA-256 is just a matter of changing the default configuration and running through the test suite. But for freelance developers who maintain ten-year-old projects in the basement, or for outsourcing teams who are still running Jenkins on CentOS 7, this is not a default change-it is a mandatory disruptive update. The cruelest thing about efficiencism is not the pursuit of efficiency, but in the name of "overall optimization", it pushes all marginal costs to the long tail that has no say.

To put it bluntly, the wave of Git 3.0 operations is essentially the harvesting of the installation base by the right to formulate standards. Just like Python 3 enforced Unicode, Java 9 modularity, and React 18 concurrency modes back then-every disruptive change in a major version is a legalized tax collection that equates migration costs to the long tail. The difference is that Python 3 solves the real pain point (Chinese garbled code), Java 9 solves the real pain point (JAR Hell), and SHA-256 defaults to solve the pseudo-pain point of "SHA-1 cannot be written in compliance documents."

The next time an RFC changes "SHOULD" to "MUST" and an infrastructure changes "experimental features" to "default on", don't just look at the technical parameters. Let me ask first: To whom did you send this migration bill? *