Git 3.0's upcoming SHA-256 default will be a costly mistake

Original Article ↗ Hacker News Discussion ↗

Git’s planned move in version 3.0 from SHA‑1 to SHA‑256 as the default hash format is prompting concern that the change will fragment the ecosystem and break decades of tooling, references, and workflows that depend on 40‑character commit IDs. Critics argue that SHA‑1’s weaknesses are largely theoretical for Git’s real-world threat model and that stronger hashes should be layered on as an additional integrity or signing mechanism, rather than replacing the core ID format in an incompatible way. Supporters of the migration counter that hash security is now a regulatory and supply‑chain requirement, but there is broad worry that the chosen path resembles past painful transitions like Python 2→3, especially around submodules, CI systems, and long-lived corporate repositories.

How serious is SHA‑1’s insecurity?

  • Many argue SHA‑1 is already “broken” (chosen‑prefix collisions, Shambles, etc.) and that relying on it for integrity or signatures is unsafe.
  • Others say practical attacks on real Git repos remain extremely hard, especially given Git’s object format and sha1dc collision‑detection, and that more probable supply‑chain attacks come via maintainer compromise or infrastructure, not hashes.
  • There is disagreement whether Git hashes are “security” or merely consistency identifiers; some point out that signing commits and pinning by hash implicitly makes them security‑critical.

Impact of making SHA‑256 the default

  • Supporters: eventually SHA‑1 must be retired; delaying only makes a future cut‑over worse. Defaults must change or nobody will move.
  • Critics: flipping the default creates two incompatible repo types, causing confusion, broken tools assuming 40‑char hashes, and hard‑to‑debug failures for users who don’t understand formats. Many analogize to IPv6 or Python 3 migrations.

Submodules, tooling, and ecosystem compatibility

  • A major fear is submodule breakage: SHA‑1 parents with SHA‑256 submodules (and vice versa) used to be described as unsupported.
  • One commenter experimentally shows SHA‑1 submodules working inside a SHA‑256 repo in recent Git, but the long‑term guarantees and corner cases remain unclear.
  • Large ecosystems (Yocto, Nix, CI/CD, language package managers) rely on commit hashes; global history rewrites would invalidate references in configs, docs, issue trackers, etc.

Forges and UX (GitHub, GitLab, self‑hosted)

  • Concern that forges will expose users to format choices they don’t understand, or mis-handle auto‑detection on first push.
  • Others counter that servers can infer format from the first push and that Git’s documented hash‑transition plan includes SHA‑1↔SHA‑256 mapping for interop.

Alternative designs and proposals

  • Popular suggestions:
    • Store both hashes per object (or separate “tree trust” hash headers) while keeping SHA‑1 IDs stable for addressing.
    • Use multihash‑style self‑describing digests or allow multiple algorithms in one repo as Fossil does.
    • Keep SHA‑1 as default; add SHA‑256 only where security or policy demands.
  • Opponents note that mixing hash strengths can degrade overall security and complicate implementation.

Security models and open questions

  • Debate over realistic attack paths: collision‑based code smuggling vs. simpler social or infra attacks.
  • Some see the migration as necessary hygiene and future‑proofing; others see it as costly “security theater.”
  • Unclear to many: exact guarantees Git 3.0 will provide for SHA‑1 lookups, submodule interop, and preserving existing external references.