LWN: Git 里面的SHA-256 支持怎么样了？

关注了就能看到更多这么棒的文章哦～

Whatever happened to SHA-256 support in Git?

By Jonathan Corbet June 23, 2022 DeepL assisted translation http://lwn.net/Articles/898522/ 

大众已经得到了这个大声的宣告：SHA-1 哈希算法已经彻底被攻破了，不应该在任何涉及安全的场合使用。从另一个角度来说，这个消息给了长期以来在 Git 源代码管理系统中支持更强大的 hash 算法的工作一些推动。然而，随着时间的推移，这项工作似乎已经放慢了脚步甚至停止了。因此有不少用户想知道，还会不会有一天可以看到 Git 支持 SHA-1 以外的哈希算法。

Hash 函数确实是 Git 能正常工作所依赖的核心机制。它的数据存储中的每个对象，包括每个文件的每个版本，以及其他的一些内容，都被采用 Hash 方式处理了，得到的值会作为该对象存储时的 key。commit 也是由代码树的当前状态、提交信息（commit message）和父提交（parent commit）的哈希值所组成的。Hash 函数的安全性是整个版本库的完整性校验的一个关键部分。如果一个攻击者可以用另一个具有相同哈希值的 commit 来替换一个 commit，那么他们可能就可以向版本库里注入恶意代码而且不会被人发现了。对于任何依赖 Git 仓库中的代码安全的人（其实也就是所有人）来说，这种前景是很可怕的。

Git 项目早已选择 SHA-256 作为 SHA-1 的替代品。Git 最初是以 SHA-1 为基础编写的，但所有这些代码后来都被重构了，可以支持多种哈希类型，SHA-256 是第二种被支持的类型。现在可以使用 SHA-256 创建 Git 仓库（只需使用 –object-format=sha256 标志），大多数本地操作就都能正常进行了。在 Git 中可以支持其他哈希算法的基础代码是 2020 年 2.29 版本的一部分，看起来实现得很可靠。

不过，2.29 版本是最后一个包含了关于替代哈希算法的重大改动的 Git 版本；自从 2021 年 3 月发布的 2.31 版本中出现过一个 fix 后，项目的 release note 中就再也没有提到过 Hash 算法替代的工作了。2.29 版本的工作将 SHA-256 标记为实验性的，并警告说 "SHA-1 和 SHA-256 存储库之间还没有支持互操作"。在 2020 年有一些关于改善互操作性的工作，但这些 patch 似乎没有被合并到 Git 主线中。

换句话说，在 Git 中支持使用 SHA-1 以外的哈希算法的工作似乎已经停滞不前。于是 Stephen Smith 最近在开发列表中发了邮件来询问其状态。Ævar Arnfjörð Bjarmason 的回答很有启发性，对于那些期待完全支持 SHA-256 的人来说，可能会让他们感到沮丧：

目前我不建议任何人使用它做什么认真的工作，就我所知，目前唯一的用户（如果有的话）是针对 git 本身进行开发的（一些）人。

Bjarmason 指出，SHA-1 和 SHA-256 库之间仍然没有互通，而且似乎没有一个 Git 托管服务商支持 SHA-256。这种支持（或不支持）是非常重要的；一个不能被推送到 Git forge 的 git 仓库对很多人来说基本上就无法使用了。另外还有一个风险（这个风险无法消除），即 SHA-256 的长哈希值可能会破坏 Git 项目之外的工具。总的来说，这个功能还没有准备好在现实世界中广泛使用。

尽管如此，值得注意的是，迄今为止完成了大部分哈希值转换工作的 Brian M. Carlson 并不同意 Bjarmason 的评估。在他看来，目前使用 SHA-1 的唯一 "站得住脚 "的理由是与 Git forge 供应商的互操作性。除此之外没有什么了。他说，SHA-1 已经过时了，使用 SHA-256 的性能可以 "大大加快"。但他也同意，所需的互操作性尚未达成，也没有人能说可以很快支持它。

至少在某种程度上，这里发生的事情看起来就像一个在自由软件历史上无数次上演的故事。一个问题已经被发现，并且已经做了大量的核心基础性工作（core foundational work）来解决这个问题。这个解决方案似乎是经过深思熟虑的，并得到了认真的实施。从某种意义上说，这项工作已经完成了 90%。剩下的就是让用户轻松过渡到新的哈希算法的困难工作了，这可以被认为是工作中 "另外 90%"。

这种接口以及兼容性的开发工作是很困难的，而且开发者通常不会觉得有什么特别的回报，所以它往往被我们的社区所忽视。有人可能会说，Git 项目特别容易出现用户接口方面的问题，这里的问题不仅仅在于此。有一些任务，志愿者往往不愿意去做，而公司也可能觉得没有必要去资助。

鉴于 SHA-1 哈希值带来了安全威胁，人们可能会认为有人会有更大的动力来支持这项工作。但是，正如 Bjarmason 所言，这种激励实际上并不那么强烈。该项目在 2017 年发布的 2.13 版本中采用了 SHA-1DC 变种，这使得该项目对已知的 SHA-1 碰撞攻击的抵抗力更加强大，因此目前对于 Git 来说似乎没有什么紧迫的攻击威胁。Bjarmason 指出，哪怕攻击者真的成功地制造出了 SHA-1 冲突，这也只是可以成功进行攻击的第一步准备工作。实现碰撞都很困难，还要找到一个仍在运行的代码，具有攻击者想要的功能，并且在人类和编译器看来都是合理的，就更难了，假如真的可以实现的话。

所以很少有人会因为 Git 仓库有可能被故意通过 SHA-1 哈希碰撞的方式破坏而坐立不安。缺乏紧迫性，以及没有兴趣做这项工作，结合起来就使向 SHA-256 的过渡陷入了停滞。也许情况会一直如此，直到 SHA-1 出现另一个弱点，使人们重新关注到这一情况。但是，正如 Randall Becker 指出的，这种不作为是会付出代价的：

提一下我的一点意见，我们中的一些人所面临的情况是，由于 SHA-1 的存在，在我们或客户组织中被阻止采用 git。在一些组织中，SHA-1 被全面禁止，无论是用来做什么。[……] 绕过这种全面的禁用就变成了一项非常重要的工作，我最近看到客户因为 SHA-1 而转向功能更少（也更难用）的旧 VCS 平台。

要说保留 SHA-1 会在不久的将来威胁到 Git 的统治地位，这还是有点牵强的。但它也许会给竞争对手提供一个立足点，从而在长期来说导致麻烦，尤其是当 SHA-1 的安全性进一步崩溃的时候。

鉴于此，人们可能会认为那些依赖 Git 的公司会看到有必要解决这个具体问题。许多公司都在使用 Git，但有些公司的整个商业模式都是围绕 Git 展开的。后者从社区对 Git 的投资中获益良多，如果 Git 不再拥有现在这个地位，那么他们也会有很大的损失。如果这些公司中的一家或多家做出相对较小的投资，来推动这一过渡的完成，似乎是很有意义的。这对社区和他们自己的未来都有好处。

全文完

LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～