Git 3.0's upcoming SHA-256 default will be a costly mistake(blog.gitbutler.com)
549 points by chmaynard 12 days ago | 521 comments
tl;dr: Git 3.0 will default new repositories to SHA-256 instead of SHA-1, forcing an ecosystem-wide migration that breaks interoperability between repos, submodules, tooling, libraries, and existing URLs/signatures — with no clean path for mixing formats. The author argues this is solving a largely theoretical problem, since real-world attacks exploit social engineering and compromised maintainers, not hash collisions. A better approach would be adding a secondary independent content hash (like SHA-256 or BLAKE3) into signed object headers, preserving SHA-1 for addressing while providing stronger verification where it matters.
HN Discussion:
  • ↓The article contains factual errors and misrepresents the real security risks of SHA-1 collision attacks
  • ↓Git's docs and actual implementation already address many of the author's concerns, including bijective mapping and submodule compatibility
  • ↓The article's screenshots and framing of the forge/UI problem are misleading or strawmen
  • ↑The SHA-256 transition is well-argued against and resembles IPv6's problematic rollout; crypto agility via signatures is preferable
  • ~The transition is driven by compliance/politics rather than real security needs, or Git should make the modes more interoperable