Git 3.0 is planning to change its default hashing algorithm from SHA-1 to SHA-256, a breaking change that according to GitButler’s analysis could create significant disruption across the software development world.
Git uses cryptographic hashing to store and verify code integrity. Since 2005, it has relied on SHA-1, which generates a 160-bit hash. According to the source, in Git’s roughly 20-year history across billions of repositories, SHA-1 has never produced an accidental collision in practice—mathematically, you would need about 1.4 septillion random files in a single project to produce an accidental match.
However, SHA-1 is now considered mathematically “semi-broken.” Published collision attacks (SHAttered in 2017 and SHA-1 is a Shambles in 2020) demonstrated that modern GPU farms could theoretically produce intentional collisions for roughly tens of thousands of dollars, a capability SHA-256 does not have.
Yet the practical attack surface may be narrower than the security concern suggests. The source distinguishes between two attack types: collision attacks (where an attacker creates two files with the same hash and switches between them) and second-preimage attacks (where an attacker creates a malicious file matching an existing file’s hash). Second-preimage attacks on SHA-1 remain computationally infeasible—even if every GPU on Earth spent 100% of its time attempting it, breaking MD5 (far weaker than SHA-1) would take roughly 11 billion years on average.
More fundamentally, according to the source, trust in Git is not primarily based on hash verification. Rather, trust derives from “where do you pull from”—the source of the code. An attacker would still need to inject malicious content into codebases through other means, regardless of hash strength.
The concern is that migrating billions of existing repositories to SHA-256 could impose substantial operational costs across the development ecosystem, while the practical security benefit against realistic attack scenarios remains unclear. The source argues that the industry needs broader discussion about whether this breaking change justifies its implementation cost.
Key facts
- Git has used SHA-1 hashing since 2005 with no accidental collisions across billions of repositories
- SHA-1 is mathematically “semi-broken” due to published collision attacks, but second-preimage attacks remain computationally infeasible
- Git 3.0 plans to default to SHA-256 to address theoretical SHA-1 vulnerabilities
- Trust in Git is based on repository source, not hash verification alone
- Migrating existing repositories to SHA-256 could create significant ecosystem-wide disruption