git客戶端是否可以保證內容完整性以抵禦受損的git服務器？

假設用戶使用特定的散列下載git存儲庫修訂版。例如用這個命令：git clone --depth 1 --branch mybranch https://mygitserver.com/x.git && cd x && git checkout {hash}。git客戶端是否可以保證內容完整性以抵禦受損的git服務器？

讓我們假設git服務器不可信，它可能會受到攻擊，以某種方式被黑客入侵。它可能試圖以某種惡意方式改變內容。

客戶端是否實際重新計算整個內容的散列值，並在散列錯誤的情況下失敗？

如果克隆很淺並且深度只有1，這意味着歷史記錄丟失。每個提交散列實際上是否包含整個源散列，或僅包含三角洲散列？看起來後者只是合理的，否則在深層歷史的情況下，它將不得不一遍又一遍地重新計算散列。

我懷疑它只是採用以前的散列，將最新的提交delta和元數據添加到它，並獲取最新的散列。代碼的哪些部分不會因最新的提交而改變？當客戶端以這種方式下載它們時，它們會計算出最新的散列嗎？

2017-06-14 Flying Jay

如果有人破壞了服務器，並對您的提交歷史記錄做了任何壞事，並替換了完整的git歷史記錄，您將永遠無法找到，除非您從其他源獲取並相互比較。你會得到一段歷史，你相信這段歷史，如果它完全被取代，你就無法弄清楚。 – ckruczek

小調：「hashtag」是Twitter上的事情，「hash」是Git所做的。 –

據我所知，Git clone和fetch不驗證對象完整性（散列不匹配）。這是根據Which git commands perform integrity checks?，但該信息可能已過時。

如果要檢查你的提交SHA-1散列是正確的，

git fsck

這證實歷史，但顯然這不會驗證你沒有對象，就像在淺水庫。

請注意，SHA-1很容易受到衝突攻擊，因此您無法在「保證」一詞的任何合理意義上用SHA-1「保證」對象完整性。

2017-06-14 05:00:24

_注意SHA-1很容易受到衝突攻擊，所以在「保證」這個詞的任何合理意義上，你不能用SHA-1「保證」對象的完整性。雖然這是真的，但從2.13開始有一個廣告 - 應該識別已知的碰撞方式。 – max630

配置變量'fetch.fsckObjects'，'receive.fsckObjects'和'transfer.fsckObjects'可以在相應的操作中自動運行 – max630

回答