Git 3.0将SHA-256设为默认哈希算法，专家指迁移成本过高

Git 3.0版本计划将默认哈希算法从SHA-1改为SHA-2561。对此，开发者Scott Chacon表示这是一项不必要的举措1。

虽然2017年的SHAttered研究和2020年的"SHA-1 is a Shambles"论文证明了SHA-1存在理论碰撞攻击可能1，但Chacon指出，在160比特输出下，产生碰撞需要1.4万亿亿个随机文件1。他认为实际安全威胁有限，现实中的攻击更可能通过社会工程学手段获得npm包维护权，而非破解哈希1。相比之下，从SHA-1迁移到SHA-256将带来巨大代价——库将不兼容、所有40字符哈希链接失效、签名破裂1。

Chacon提出了替代方案：在签名对象中注入独立计算的SHA-256树哈希头，同时保留SHA-1作为内容寻址键1。这一方案可以在不改动整个Git生态的前提下增强内容信任验证1。独立校验的性能开销并不显著，Chromium树（35GB、2.1M文件）的验证耗时仅5秒，Linux树257毫秒，Git项目本身仅17毫秒1。此外，NIST 2030年的SHA-1停用期限仅适用于"密码学保护应用"，而非存在于任何软件栈中1。

Git's planned shift to SHA-256 as the default hashing algorithm in version 3.0 represents an unnecessary migration that will impose substantial costs despite limited practical security gains, according to analysis by Git developer Scott Chacon 1. While SHA-1 faces theoretical vulnerabilities documented in academic research, the actual threat landscape suggests alternative approaches would better serve the ecosystem.

The mathematical case against SHA-1 centers on collision possibilities: generating a hash collision with SHA-1's 160-bit output would require approximately 1.4 quintillion random files 1. Academic papers, including SHAttered in 2017 and SHA-1 is a Shambles in 2020, have demonstrated theoretical collision attack vectors 1. However, Chacon argues that real-world attacks targeting Git repositories are more likely to succeed through social engineering—such as compromising npm package maintainer accounts—than through cryptographic breakthroughs 1. The NIST deadline for SHA-1 retirement in 2030 specifically applies to "cryptographically protected applications" rather than to hash functions existing anywhere in software stacks 1.

The migration to SHA-256 would trigger widespread breakage across the Git ecosystem 1. All 40-character SHA-1 hash references would become invalid, breaking existing links, library compatibility would fracture, and cryptographic signatures would fail 1. Instead, Chacon proposes embedding independently calculated SHA-256 tree hash headers directly into signature objects while retaining SHA-1 as the content addressing key 1. Testing shows this approach imposes minimal overhead: verification takes 5 seconds for Chromium's 35-gigabyte repository with 2.1 million files, 257 milliseconds for Linux, and just 17 milliseconds for Git's own repository 1.