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 深度文章以及開源社區的各種新近言論～