Git 3.0 要把 SHA-1 換成 SHA-256為什么有人把它比作「又一個 IPv6」GitButler 的創(chuàng)始人 Scott Chacon 前幾天寫了一篇博客標(biāo)題直接把結(jié)論擺在臉上Git 3.0’s upcoming SHA-256 default will be a costly mistake。Hacker News 的討論帖 半天沖到 359 分、342 條評論。Chacon 不是外人。他是《Pro Git》的作者日常做的就是 Git 客戶端。他一開口說「這是個代價高昂的錯誤」評論區(qū)立刻分成兩派。但真正值得看的不是誰嗓門大而是這場爭論把一個老問題重新擺到了臺面上當(dāng)一個系統(tǒng)的標(biāo)識符變成了所有人依賴的不可變契約換掉它到底是一次升級還是一場生態(tài)拆遷先說清楚 Git 為什么要換Git 本質(zhì)上是一個內(nèi)容尋址的文件系統(tǒng)。文件、目錄、提交全部用哈希值而不是遞增序號來命名。Git 官方文檔寫得很直白用哈希尋址好處是完整性校驗極其簡單——哪怕只有一個 bit 翻轉(zhuǎn)算出來的哈希對不上名字當(dāng)場暴露。問題是哈希算法本身會老。2017 年 2 月 23 日SHAttered 攻擊演示了第一個真實的 SHA-1 碰撞兩份內(nèi)容不同、哈希相同的 PDF。Git 從 v2.13.0 起默認(rèn)換成硬化版 SHA-1躲開了那次攻擊但官方文檔的口徑依然謹(jǐn)慎——沒人能保證以后不出現(xiàn)新的、并且沒有緩解方案的攻擊。所以把默認(rèn)哈希從 SHA-1 換成 SHA-256被寫進(jìn)了 Git 3.0 的計劃。爭議一碰撞攻擊到底算不算威脅Chacon 的核心論點之一是Git 里真正的威脅是「第二原像攻擊」而不是「碰撞攻擊」。這兩種攻擊確實不是一回事。碰撞攻擊是主動造出一對文件讓它們哈希相同第二原像攻擊是拿到一份已知文件硬湊出另一份哈希也相同的文件——后者難得多。他的理由是 Git 對象在哈希前會帶一個頭部類似blob 1234\0攻擊者沒法直接復(fù)用公開的碰撞樣本成本會被推高。這條立刻被頂?shù)搅税袷?。一位用戶列出三點反駁其中第二點最要命碰撞攻擊在 Git 里完全夠用。場景是兩個倉庫引用同一個提交哈希但檢出后的代碼內(nèi)容不同——這就是代碼走私而校驗哈希根本沒有意義因為它們確實一模一樣。評論區(qū)另一位補了一刀在一個人人都會對陌生人的 PR 執(zhí)行g(shù)it fetch的世界里「只要你 fetch 了就已經(jīng)中招」不能當(dāng)成安全邊界。爭議二真正的難點在密碼學(xué)之外比起密碼學(xué)細(xì)節(jié)遷移工程才是這場爭論真正的火藥桶。Git 官方文檔里其實已經(jīng)寫了一套相當(dāng)克制的方案新舊命名可以并存老提交用 SHA-1 名字依然有效維護(hù)一張 SHA-1 與 SHA-256 的雙向映射表并且刻意做成一一對應(yīng)這樣換算是可逆的、能按需重算不必把所有對象重新哈希一遍。但一一對應(yīng)也帶來了硬約束。文檔明確寫著不允許混合倉庫子模塊必須和父倉庫使用同一種算法。再疊上現(xiàn)實一層——GitHub 目前根本不支持 SHA-256 倉庫的 push而這正是拖住 3.0 的主要原因之一。對照之下有一組數(shù)據(jù)特別刺眼。Fossil SCMSQLite 團(tuán)隊做的版本控制系統(tǒng)在 SHAttered 公布后第 6 天——2017 年 3 月 1 日——就加上了 SHA3-256 選項如今新倉庫全部默認(rèn)。更關(guān)鍵的是沒有倉庫被重建也沒有超鏈接失效。一邊是 6 天一邊是從 2017 年談到今天的多年規(guī)劃。差距不在密碼學(xué)在生態(tài)規(guī)模。替代方案和一條更值得記的批評Chacon 提了一個有意思的想法獨立樹哈希頭。不改尋址方式而是用另一種算法獨立地把樹內(nèi)容再算一遍哈希把兩個哈希一起簽名——SHA-1 負(fù)責(zé)檢索內(nèi)容SHA-256 負(fù)責(zé)獨立驗證內(nèi)容。評論區(qū)有人覺得這個方向值得深挖也有人反駁說它并不能真正替代格式層面的遷移。支持「該換」的聲音里同樣有一條批評非常值得記如果你只是把 SHA-1 換成 SHA-256那你遲早還得再換一次。真正的問題不是這次選哪個哈希而是 Git 的設(shè)計壓根沒給「加密敏捷性」crypto agility留位置——算法被硬編碼進(jìn)了對象格式換一次就要動整個生態(tài)。也有讀者站出來為換默認(rèn)辯護(hù)2024 年給一個隨機(jī)的 SHA-1 哈希找一個碰撞成本大約只有一萬美元。對大多數(shù)威脅模型來說這等于不可行但它攔不住規(guī)模繼續(xù)擴(kuò)大——今天不換將來就是明擺著的坑。順帶一提還有一條容易被忽略的實用視角真有組織是因為合規(guī)要求才推這件事。SHA-1 在 FIPS 140-2 一類認(rèn)證里被明確不推薦某些機(jī)構(gòu)甚至一刀切禁用。這也解釋了為什么「Git 里哈希不是安全特性」這個技術(shù)判斷并不能讓遷移停下來。一個判斷這場爭論表面在吵「SHA-1 還安不安全」實質(zhì)在吵一個更難的工程問題當(dāng)系統(tǒng)的標(biāo)識符變成了對外契約算法升級就不再是本地重構(gòu)而是分布式系統(tǒng)的一致性遷移。Git 的對象名會被寫進(jìn)提交信息、CI 腳本、部署記錄、issue 評論。有人舉了個很實在的例子遷移之后所有寫著「see commit abc1234」的歷史提交信息全部失效。這不是安全問題這是引用語義被改掉了。對開發(fā)者的啟示其實很樸素設(shè)計任何 ID schema不只是版本控制系統(tǒng)也包括數(shù)據(jù)庫主鍵、內(nèi)容尋址存儲、緩存鍵時把算法版本位留出來。一代人換一次的東西值得在格式里預(yù)留一個版本號而不是等到下一次被迫全量遷移。至于這場爭論本身值不值得信——與其只讀博客和評論區(qū)不如自己拿一套固定的對照測試跑一遍如果需要在多個模型或工具之間做這種橫向?qū)Ρ萳ikeai520.cc 這類 API 中轉(zhuǎn)可以省掉一部分逐家接入和驗證的工作。能跑、能對比、能被驗證的結(jié)論才值得寫進(jìn)你的技術(shù)選型。主要參考GitButler 原文、Hacker News 討論帖id49924179、Git 官方 hash-function-transition 文檔、SHAttered 攻擊、Fossil SCM 遷移記錄 Git 3.0 要把 SHA-1 換成 SHA-256，為什么有人把它比作「又一個 IPv6」？
Git 3.0 要把 SHA-1 換成 SHA-256為什么有人把它比作「又一個 IPv6」GitButler 的創(chuàng)始人 Scott Chacon 前幾天寫了一篇博客標(biāo)題直接把結(jié)論擺在臉上Git 3.0’s upcoming SHA-256 default will be a costly mistake。Hacker News 的討論帖 半天沖到 359 分、342 條評論。Chacon 不是外人。他是《Pro Git》的作者日常做的就是 Git 客戶端。他一開口說「這是個代價高昂的錯誤」評論區(qū)立刻分成兩派。但真正值得看的不是誰嗓門大而是這場爭論把一個老問題重新擺到了臺面上當(dāng)一個系統(tǒng)的標(biāo)識符變成了所有人依賴的不可變契約換掉它到底是一次升級還是一場生態(tài)拆遷先說清楚 Git 為什么要換Git 本質(zhì)上是一個內(nèi)容尋址的文件系統(tǒng)。文件、目錄、提交全部用哈希值而不是遞增序號來命名。Git 官方文檔寫得很直白用哈希尋址好處是完整性校驗極其簡單——哪怕只有一個 bit 翻轉(zhuǎn)算出來的哈希對不上名字當(dāng)場暴露。問題是哈希算法本身會老。2017 年 2 月 23 日SHAttered 攻擊演示了第一個真實的 SHA-1 碰撞兩份內(nèi)容不同、哈希相同的 PDF。Git 從 v2.13.0 起默認(rèn)換成硬化版 SHA-1躲開了那次攻擊但官方文檔的口徑依然謹(jǐn)慎——沒人能保證以后不出現(xiàn)新的、并且沒有緩解方案的攻擊。所以把默認(rèn)哈希從 SHA-1 換成 SHA-256被寫進(jìn)了 Git 3.0 的計劃。爭議一碰撞攻擊到底算不算威脅Chacon 的核心論點之一是Git 里真正的威脅是「第二原像攻擊」而不是「碰撞攻擊」。這兩種攻擊確實不是一回事。碰撞攻擊是主動造出一對文件讓它們哈希相同第二原像攻擊是拿到一份已知文件硬湊出另一份哈希也相同的文件——后者難得多。他的理由是 Git 對象在哈希前會帶一個頭部類似blob 1234\0攻擊者沒法直接復(fù)用公開的碰撞樣本成本會被推高。這條立刻被頂?shù)搅税袷?。一位用戶列出三點反駁其中第二點最要命碰撞攻擊在 Git 里完全夠用。場景是兩個倉庫引用同一個提交哈希但檢出后的代碼內(nèi)容不同——這就是代碼走私而校驗哈希根本沒有意義因為它們確實一模一樣。評論區(qū)另一位補了一刀在一個人人都會對陌生人的 PR 執(zhí)行g(shù)it fetch的世界里「只要你 fetch 了就已經(jīng)中招」不能當(dāng)成安全邊界。爭議二真正的難點在密碼學(xué)之外比起密碼學(xué)細(xì)節(jié)遷移工程才是這場爭論真正的火藥桶。Git 官方文檔里其實已經(jīng)寫了一套相當(dāng)克制的方案新舊命名可以并存老提交用 SHA-1 名字依然有效維護(hù)一張 SHA-1 與 SHA-256 的雙向映射表并且刻意做成一一對應(yīng)這樣換算是可逆的、能按需重算不必把所有對象重新哈希一遍。但一一對應(yīng)也帶來了硬約束。文檔明確寫著不允許混合倉庫子模塊必須和父倉庫使用同一種算法。再疊上現(xiàn)實一層——GitHub 目前根本不支持 SHA-256 倉庫的 push而這正是拖住 3.0 的主要原因之一。對照之下有一組數(shù)據(jù)特別刺眼。Fossil SCMSQLite 團(tuán)隊做的版本控制系統(tǒng)在 SHAttered 公布后第 6 天——2017 年 3 月 1 日——就加上了 SHA3-256 選項如今新倉庫全部默認(rèn)。更關(guān)鍵的是沒有倉庫被重建也沒有超鏈接失效。一邊是 6 天一邊是從 2017 年談到今天的多年規(guī)劃。差距不在密碼學(xué)在生態(tài)規(guī)模。替代方案和一條更值得記的批評Chacon 提了一個有意思的想法獨立樹哈希頭。不改尋址方式而是用另一種算法獨立地把樹內(nèi)容再算一遍哈希把兩個哈希一起簽名——SHA-1 負(fù)責(zé)檢索內(nèi)容SHA-256 負(fù)責(zé)獨立驗證內(nèi)容。評論區(qū)有人覺得這個方向值得深挖也有人反駁說它并不能真正替代格式層面的遷移。支持「該換」的聲音里同樣有一條批評非常值得記如果你只是把 SHA-1 換成 SHA-256那你遲早還得再換一次。真正的問題不是這次選哪個哈希而是 Git 的設(shè)計壓根沒給「加密敏捷性」crypto agility留位置——算法被硬編碼進(jìn)了對象格式換一次就要動整個生態(tài)。也有讀者站出來為換默認(rèn)辯護(hù)2024 年給一個隨機(jī)的 SHA-1 哈希找一個碰撞成本大約只有一萬美元。對大多數(shù)威脅模型來說這等于不可行但它攔不住規(guī)模繼續(xù)擴(kuò)大——今天不換將來就是明擺著的坑。順帶一提還有一條容易被忽略的實用視角真有組織是因為合規(guī)要求才推這件事。SHA-1 在 FIPS 140-2 一類認(rèn)證里被明確不推薦某些機(jī)構(gòu)甚至一刀切禁用。這也解釋了為什么「Git 里哈希不是安全特性」這個技術(shù)判斷并不能讓遷移停下來。一個判斷這場爭論表面在吵「SHA-1 還安不安全」實質(zhì)在吵一個更難的工程問題當(dāng)系統(tǒng)的標(biāo)識符變成了對外契約算法升級就不再是本地重構(gòu)而是分布式系統(tǒng)的一致性遷移。Git 的對象名會被寫進(jìn)提交信息、CI 腳本、部署記錄、issue 評論。有人舉了個很實在的例子遷移之后所有寫著「see commit abc1234」的歷史提交信息全部失效。這不是安全問題這是引用語義被改掉了。對開發(fā)者的啟示其實很樸素設(shè)計任何 ID schema不只是版本控制系統(tǒng)也包括數(shù)據(jù)庫主鍵、內(nèi)容尋址存儲、緩存鍵時把算法版本位留出來。一代人換一次的東西值得在格式里預(yù)留一個版本號而不是等到下一次被迫全量遷移。至于這場爭論本身值不值得信——與其只讀博客和評論區(qū)不如自己拿一套固定的對照測試跑一遍如果需要在多個模型或工具之間做這種橫向?qū)Ρ萳ikeai520.cc 這類 API 中轉(zhuǎn)可以省掉一部分逐家接入和驗證的工作。能跑、能對比、能被驗證的結(jié)論才值得寫進(jìn)你的技術(shù)選型。主要參考GitButler 原文、Hacker News 討論帖id49924179、Git 官方 hash-function-transition 文檔、SHAttered 攻擊、Fossil SCM 遷移記錄