Git 3.0 is preparing to change its default hash algorithm from SHA-1 to SHA-256, a move the project frames as a necessary security upgrade. The argument: SHA-1 is cryptographically "broken" — published collision attacks (SHAttered in 2017, SHA-1 is a Shambles in 2020) have demonstrated that sufficiently motivated attackers can, with enough GPU time and money, manufacture two different files that produce the same hash. SHA-256 does not have this weakness. Case closed, right? Not remotely. The author — who has been watching this unfold for years — makes a sharp distinction that the Git security conversation consistently elides: the difference between collision attacks and second-preimage attacks. A collision attack requires the attacker to generate both the benign and malicious file from scratch, then socially engineer the benign version into a trusted position before swapping. A second-preimage attack — targeting an existing file you didn't author — remains computationally infeasible against SHA-1 and even against the thoroughly demolished MD5. If every one of Earth's roughly 3 billion GPUs were replaced with an RTX 5090 and set to brute-forcing MD5 preimages full-time, the expected time to succeed would be approximately 16 billion years. The core argument is devastating in its simplicity: hashing is not the mechanism of trust in software supply chains. Linus Torvalds said exactly this in 2005 — "the real security is in distribution." You pull code from github.com/rust-lang/rust because you trust GitHub's access controls, code review processes, and the maintainer community, not because you independently verify GPG signatures against collision-resistant hashes. The hash provides integrity confirmation, not trust establishment. Meanwhile, actual supply-chain attacks — the ones that have cost real organizations real money — exploit social engineering, maintainer burnout, and low-trust package management forges. The xz Utils backdoor, the event-stream npm hijack, the ua-parser-js compromise: none of these involved hash collisions. They involved humans. A tired open-source maintainer handing over commit access for a $40,000 lump sum is a billion times cheaper, simpler, and more likely to succeed than renting a GPU farm to brute-force a SHA-1 collision and then somehow getting victims to fetch from an untrusted URL. The migration cost, however, is very real. SHA-256 hashes are incompatible with SHA-1 hashes. Every tool, CI pipeline, hook script, and integration that handles Git object IDs will need updating. Repository interoperability between SHA-1 and SHA-256 repos requires translation layers. The ecosystem friction will be measured in millions of developer-hours globally, spread across every team that uses Git — which is effectively every software team on Earth. This is a textbook case of solving the legible problem instead of the important one. Hash algorithm upgrades are clean, mathematical, demonstrable improvements that can be pointed to in audit reports and compliance checklists. Fixing the actual trust infrastructure of open-source — maintainer compensation, dependency review, forge security, social engineering resistance — is messy, expensive, and doesn't fit on a slide. The Git project is doing the thing that looks like security rather than the thing that produces it. The author's implicit question deserves an explicit answer from the Git maintainers: given the actual attack surface, given the real-world cost of migration, and given that SHA-1's weaknesses do not translate into practical Git exploits, what is the concrete threat model that justifies imposing this cost on the entire global development ecosystem?
