首頁(yè) 猿問(wèn) Git如何處理blob上的SHA-...

Git如何處理blob上的SHA-1沖突？

Git

吃雞游戲 2019-08-29 08:34:09

Git如何處理blob上的SHA-1沖突？這可能永遠(yuǎn)不會(huì)發(fā)生在現(xiàn)實(shí)世界中，并且可能永遠(yuǎn)不會(huì)發(fā)生，但讓我們考慮一下：假設(shè)您有一個(gè)git存儲(chǔ)庫(kù)，進(jìn)行提交，并且變得非常不幸：其中一個(gè)blob最終擁有相同的SHA-1另一個(gè)已存在于您的存儲(chǔ)庫(kù)中。問(wèn)題是，Git將如何處理這個(gè)？簡(jiǎn)直失敗了？找到一種方法來(lái)鏈接兩個(gè)blob并根據(jù)上下文檢查哪一個(gè)需要？更多的是腦筋急轉(zhuǎn)彎而非實(shí)際問(wèn)題，但我發(fā)現(xiàn)這個(gè)問(wèn)題很有趣。

查看完整描述

3 回答

米琪卡哇伊

TA貢獻(xiàn)1998條經(jīng)驗(yàn) 獲得超6個(gè)贊

原始答案（2012）（見(jiàn)shattered.io下面的2017 SHA1碰撞）

Linus的那個(gè)舊的（2006）答案可能仍然是相關(guān)的：

不。如果它具有相同的SHA1，則意味著當(dāng)我們從另一端接收到對(duì)象時(shí)，我們將不會(huì)覆蓋我們已有的對(duì)象。
所以會(huì)發(fā)生的是，如果我們看到碰撞，任何特定存儲(chǔ)庫(kù)中的“早期”對(duì)象將始終最終覆蓋。但請(qǐng)注意，“早期”顯然是每個(gè)存儲(chǔ)庫(kù)，因?yàn)間it對(duì)象網(wǎng)絡(luò)生成的DAG不是完全有序的，因此雖然不同的存儲(chǔ)庫(kù)會(huì)同意直接祖先情況下的“早期”，如果對(duì)象來(lái)自分離而非直接相關(guān)的分支，兩個(gè)不同的回購(gòu)可能顯然已經(jīng)得到了不同順序的兩個(gè)對(duì)象。
但是，從安全角度來(lái)看，“早先將覆蓋”非常符合您的要求：請(qǐng)記住，git模型是您應(yīng)該主要只信任自己的存儲(chǔ)庫(kù)。
因此，如果你執(zhí)行“ git pull”，新的傳入對(duì)象根據(jù)定義不如你已經(jīng)擁有的對(duì)象值得信任，因此允許新對(duì)象替換舊對(duì)象是錯(cuò)誤的。
所以你有兩種碰撞案例：
在不經(jīng)意的那種，你不知何故是非常非常不走運(yùn)，而兩個(gè)文件最終具有相同SHA1。
此時(shí)，當(dāng)您提交該文件（或執(zhí)行“ git-update-index”將其移入索引但尚未提交）時(shí)，會(huì)計(jì)算新內(nèi)容的SHA1，但由于它與舊對(duì)象匹配，將不會(huì)創(chuàng)建新對(duì)象，并且commit-or-index最終指向舊對(duì)象。
您不會(huì)立即注意到（因?yàn)樗饕龑⑴c舊對(duì)象SHA1匹配，這意味著像“ git diff” 這樣的東西將使用簽出的副本），但是如果你曾經(jīng)做過(guò)樹(shù)級(jí)差異（或者你做了克?。┗蚶?，或強(qiáng)制結(jié)帳）你會(huì)突然注意到該文件已更改為某些內(nèi)容與你的預(yù)期完全不同。
所以你通常會(huì)很快注意到這種碰撞。
在相關(guān)的新聞中，問(wèn)題是如何處理無(wú)意中的碰撞。
首先，讓我提醒人們，無(wú)意中的碰撞實(shí)際上真的不太可能，所以我們很可能永遠(yuǎn)不會(huì)在完整的歷史中看到它宇宙
但是如果它發(fā)生了，那就不是世界末日：你最有可能要做的就是改變稍微相撞的文件，并強(qiáng)制使用更改的內(nèi)容強(qiáng)制進(jìn)行新的提交（添加注釋說(shuō)“ /* This line added to avoid collision */”）和然后教git關(guān)于已被證明是危險(xiǎn)的魔法SHA1。
因此，在幾百萬(wàn)年中，我們可能必須向git添加一個(gè)或兩個(gè)“中毒”SHA1值。這不太可能成為維護(hù)問(wèn)題;）
該攻擊者那種碰撞，因?yàn)橛腥舜蚱疲ɑ蛞靶U強(qiáng)制）SHA1。
這一個(gè)顯然是一個(gè)很多比無(wú)意樣的可能性較大，但顧名思義它總是一個(gè)“遠(yuǎn)程”庫(kù)。如果攻擊者可以訪問(wèn)本地存儲(chǔ)庫(kù)，他就會(huì)有更容易的方法來(lái)阻止你。
所以在這種情況下，碰撞完全不是問(wèn)題：你會(huì)得到一個(gè)與攻擊者意圖不同的“壞”存儲(chǔ)庫(kù)，但是因?yàn)槟阌肋h(yuǎn)不會(huì)真正使用他的碰撞對(duì)象，所以它實(shí)際上與攻擊者根本沒(méi)有發(fā)現(xiàn)碰撞，但只是使用你已經(jīng)擁有的對(duì)象（即它100％相當(dāng)于生成相同SHA1的相同文件的“普通”沖突）。

經(jīng)常提到使用SHA-256的問(wèn)題，但現(xiàn)在不采取行動(dòng)（2012）。
注意：從2018和Git 2.19開(kāi)始，代碼被重構(gòu)為使用SHA-256。

注（幽默）：你可以強(qiáng)制提交到一個(gè)特定的SHA1 前綴，項(xiàng)目gitbrute從布拉德·菲茨帕特里克（bradfitz）。

gitbrute強(qiáng)制執(zhí)行一對(duì)作者+提交者時(shí)間戳，以便生成的git commit具有您想要的前綴。

示例：https：//github.com/bradfitz/deadbeef

丹尼爾Dinnyes指出，在評(píng)論中，以7.1的Git工具-修正選擇，其中包括：

更高的可能性是你的編程團(tuán)隊(duì)的每個(gè)成員都會(huì)在同一天晚上被無(wú)關(guān)緊要的事件中的狼襲擊和殺死。

即便是最近（2017年2月）也shattered.io證明了造成SHA1碰撞的可能性:(
請(qǐng)參閱我的單獨(dú)答案中的更多信息，包括Linus Torvalds的Google+帖子）

a /仍需要超過(guò)9,223,372,036,854,775,808個(gè)SHA1計(jì)算。這需要相當(dāng)于6,500年單CPU計(jì)算和110年單GPU計(jì)算的處理能力。
b /會(huì)偽造一個(gè)文件（使用相同的SHA1），但是使用附加約束，其內(nèi)容和大小會(huì)產(chǎn)生相同的SHA1（單獨(dú)內(nèi)容上的沖突是不夠的）：請(qǐng)參閱“ 如何計(jì)算git哈希？ ”）：blob SHA1基于內(nèi)容和大小計(jì)算。

有關(guān)更多信息，請(qǐng)參閱Valerie Anita Aurora的 “ 加密哈希函數(shù)的生命周期 ” 。在那頁(yè)中，她指出：