在 Hacker News 首頁上的「Whatever happened to SHA-256 support in Git?」這篇，大概半年前，今年六月的文章，在講 Git 在 SHA-256 支援上遇到的問題。

最大的問題還是沒有 transition plan：

Bjarmason pointed out that there is still no interoperability between SHA-1 and SHA-256 repositories, and that none of the Git hosting providers appear to be supporting SHA-256.

這點導致了目前場上看的到的服務與 open source 軟體都沒有支援的計畫，這點算是一個超級失敗的 transition plan。

另外乾脆請 OpenAI 的 ChatGPT 幫忙寫：

Git是一種源代碼管理系統，它使用散列函數將每個對象（例如文件的每個版本）和每個提交都轉換為一個數值，用於存儲該對象。散列函數的安全性是整個倉庫完整性的重要組成部分。如果攻擊者可以用具有相同散列值的另一個提交替換提交，他們可能會在不冒檢測風險的情況下將惡意代碼植入倉庫中。這種前景令任何依賴 Git 倉庫中代碼安全性的人感到擔心，也就是所有人。

Git 項目早已選擇 SHA-256 作為 SHA-1 的替代品。Git 最初是使用 SHA-1 寫成的，但是這些代碼已被重構，並且可以處理多種散列類型，其中 SHA-256 是第二種支持的類型。現在可以使用 SHA-256 創建 Git 倉庫（只需使用 --object-format=sha256 標誌），大多數本地操作都會正常工作。Git 中支持替代散列算法的基礎是2020年發布的2.29版本的一部分，並且似乎很穩定。

然而，自從2021年3月發布的2.31版本中出現了修復程序以來，2.29版本是最後一個在任何重大方面支持替代散列的版本。專

續寫前文，Git 專案在支持 SHA-256 之前一直使用 SHA-1 作為散列算法。然而，由於 SHA-1 的終極破解，Git 項目被迫尋找替代方案。Git 原本的代碼是深深地嵌入 SHA-1 的，但是這些代碼已經被重構，並且可以處理多種散列類型，其中 SHA-256 是第二種支持的類型。因此，現在可以使用 SHA-256 創建 Git 倉庫（只需使用 --object-format=sha256 標誌），大多數本地操作都會正常工作。

然而，目前尚不存在 SHA-1 和 SHA-256 倉庫之間的相互操作性，並且 Git 托管提供商似乎都不支持 SHA-256。這種支持（或缺乏支持）很重要，因為無法推送到 Git 熔爐的倉庫對許多人來說將是無用的。此外，使用 SHA-256 的較長散列可能會破壞 Git 項目以外開發的工具，這種風險也無法完全消除。整體而言，這是一種尚未準備好用於現實世界的功能。

雖然如此，值得注意的是，迄今為止完成大部分散列轉換工作的 brian m. carlson 對 Bjarmason 的評估持不同看法。在他看來，目前唯一“可以辯解

的”使用 SHA-1 的原因是與 Git 熔爐提供商的相互操作性。否則，他認為 SHA-1 已經過時，並且使用 SHA-256 的性能可能“大幅提升”。但是，他同意所需的相互操作性目前尚不存在，且沒有人表示它即將在短期內到來。

因此，目前看來，Git 專案在支持 SHA-256 方面的工作似乎已經停止。至於什麼原因導致了這種情況，目前還不清楚。但是，這並不意味著 Git 將永遠不會支持 SHA-256 或其他散列算法。相反，可能是因為尚未解決所有技術問題，或者可能是因為其他原因（例如技術資源有限）。無論原因是什麼，重要的是要記住，Git 項目的開發人員一直在努力使其更強大、更安全，並且將繼續努力。

To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)