Git 3.0 默认 SHA-256 引发争论：GitHub 兼容缺口与「昂贵噩梦」之辩

Git 3.0 计划把新仓库的默认对象格式从 SHA-1 改为 SHA-256（现已可用 git init –object-format=sha256 体验）。GitHub 与 GitButler 联合创始人 Scott Chacon（Pro Git 作者）发文反对，把这场迁移称为「难以理解的昂贵、最终无价值且可避免的全球噩梦」。

事实部分

• 变更内容：Git 3.0 新仓库默认 SHA-256 对象格式。
• Chacon 的论点：SHA-1 在 Git 场景的现实威胁是碰撞攻击（可伪造提交），而非第二原像攻击（无法篡改已有提交）；「真正的安全在于分发」——他引用 Linus 2005 年的话。
• 替代方案：独立的树哈希头（双签 SHA-1 + SHA-256/BLAKE3，沿 git-evtag 思路）；其 PoC 在 5 秒内哈希完 Chromium 的 35GB、210 万文件树（github.com/schacon/tree-sha256）。
• 关键事实：GitHub 目前不支持推送 SHA-256 仓库——Chacon 称这是「推迟 3.0 的主要原因」。
• 合规时钟：NIST 要求 2030 年前停用 SHA-1。

迁移的真实成本

对象格式变更意味着每个托管平台、每个 CI 系统、每个本地钩子都要兼容双格式——Git 社区上一次全球性迁移（SHA-1→SHA-256 讨论）拖了八年没落地。GitHub 的支持进度是事实上的闸门。

双哈希路线的合理性

Chacon 的方案本质是「加签名不改地基」：保留 SHA-1 兼容性，用树级 SHA-256/BLAKE3 头提供防篡改证明。反对者会指出这留下 SHA-1 碰撞攻击面（攻击者仍可制造两个相同 SHA-1 的提交对象，只是树头不同）；支持者认为配合分发验证已足够。这是密码学工程与运维成本的经典权衡。

与其他基础设施治理的呼应

同周的基础设施治理动作还有 arXiv 的提交限流与 Cloudflare 的 K2 事件流：三件事都在回答同一个问题——全球性基础设施的默认值与规则由谁、以什么节奏改变。

编辑判断

对普通开发者，2026 年的可执行建议不变：重要仓库开启 push 时校验与签名（gpgsig/ssh 签名），托管平台升级后跟进默认格式。这场争论的真正价值是把「密码学正确」与「运维可行」的张力摆上台面——Git 作为全球基础设施，任何默认值变更都是十年的事。

反方观点的公平陈述

支持 SHA-256 的一方有真实论据：SHA-1 自 2017 年（SHAttered）起就有实用碰撞攻击，NIST 的 2030 大限不远，而且「双哈希头」即便在 checkout 时能被树头拦住，碰撞伪造的提交对象仍然留在了对象库里。安全研究者要这个默认值已经很多年。Chacon 给争论新增的是一本运维账——平台兼容矩阵与更便宜的替代方案——这是 Git 维护者的路线图至今没有公开回应的部分。

对托管平台运营者的意义

比 GitHub 小的托管方在同一个缺口前资源更少：GitLab 与 Forgejo 的 SHA-256 支持落后于格式变更，自建 Gitea 更靠后。现实的迁移顺序应该是：平台先支持推送，Git 再翻默认值——如果眼下的分歧维持，接下来要么是双格式过渡期，要么是 Chacon 警告的碎片化。自建 Git 的团队现在就该去提 SHA-256 支持需求，别等 3.0 发布。 默认值就是基础设施政策，这一条要接受十年的检验。

历史的押韵

这是 Git 哈希迁移第二次卡在生态就绪而非密码学上——最初的 SHA-256 计划 2017 年就有，卡在与今天相同的平台支持问题上；这中间补上的签名基础设施（gpgsig、SSH key、Sigstore）让 Chacon 的树头方案比 2018 年时可信得多。无论站哪边，争论本身是真实的：两条都可信的路线、一个截止日期、一个替所有人做决定的平台支持时间表。 树头方案 5 秒哈希 35GB 的 PoC 是整篇论证里最硬的物证。