Git如何处理blob上的SHA-1冲突？

原始答案（2012）（见shattered.io下面的2017 SHA1碰撞）Linus的那个旧的（2006）答案可能仍然是相关的：不。如果它具有相同的SHA1，则意味着当我们从另一端接收到对象时，我们将不会覆盖我们已有的对象。所以会发生的是，如果我们看到碰撞，任何特定存储库中的“早期”对象将始终最终覆盖。但请注意，“早期”显然是每个存储库，因为git对象网络生成的DAG不是完全有序的，因此虽然不同的存储库会同意直接祖先情况下的“早期”，如果对象来自分离而非直接相关的分支，两个不同的回购可能显然已经得到了不同顺序的两个对象。但是，从安全角度来看，“早先将覆盖”非常符合您的要求：请记住，git模型是您应该主要只信任自己的存储库。因此，如果你执行“ git pull”，新的传入对象根据定义不如你已经拥有的对象值得信任，因此允许新对象替换旧对象是错误的。所以你有两种碰撞案例：在不经意的那种，你不知何故是非常非常不走运，而两个文件最终具有相同SHA1。此时，当您提交该文件（或执行“ git-update-index”将其移入索引但尚未提交）时，会计算新内容的SHA1，但由于它与旧对象匹配，将不会创建新对象，并且commit-or-index最终指向旧对象。您不会立即注意到（因为索引将与旧对象SHA1匹配，这意味着像“ git diff” 这样的东西将使用签出的副本），但是如果你曾经做过树级差异（或者你做了克隆）或拉，或强制结帐）你会突然注意到该文件已更改为某些内容与你的预期完全不同。所以你通常会很快注意到这种碰撞。在相关的新闻中，问题是如何处理无意中的碰撞。首先，让我提醒人们，无意中的碰撞实际上真的不太可能，所以我们很可能永远不会在完整的历史中看到它宇宙 但是如果它发生了，那就不是世界末日：你最有可能要做的就是改变稍微相撞的文件，并强制使用更改的内容强制进行新的提交（添加注释说“ /* This line added to avoid collision */”）和然后教git关于已被证明是危险的魔法SHA1。因此，在几百万年中，我们可能必须向git添加一个或两个“中毒”SHA1值。这不太可能成为维护问题;）该攻击者那种碰撞，因为有人打破（或野蛮强制）SHA1。这一个显然是一个很多比无意样的可能性较大，但顾名思义它总是一个“远程”库。如果攻击者可以访问本地存储库，他就会有更容易的方法来阻止你。所以在这种情况下，碰撞完全不是问题：你会得到一个与攻击者意图不同的“坏”存储库，但是因为你永远不会真正使用他的碰撞对象，所以它实际上与攻击者根本没有发现碰撞，但只是使用你已经拥有的对象（即它100％相当于生成相同SHA1的相同文件的“普通”冲突）。经常提到使用SHA-256的问题，但现在不采取行动（2012）。注意：从2018和Git 2.19开始，代码被重构为使用SHA-256。注（幽默）：你可以强制提交到一个特定的SHA1 前缀，项目gitbrute从布拉德·菲茨帕特里克（bradfitz）。gitbrute强制执行一对作者+提交者时间戳，以便生成的git commit具有您想要的前缀。示例：https：//github.com/bradfitz/deadbeef丹尼尔Dinnyes指出，在评论中，以7.1的Git工具-修正选择，其中包括：更高的可能性是你的编程团队的每个成员都会在同一天晚上被无关紧要的事件中的狼袭击和杀死。即便是最近（2017年2月）也shattered.io证明了造成SHA1碰撞的可能性:( 请参阅我的单独答案中的更多信息，包括Linus Torvalds的Google+帖子）a /仍需要超过9,223,372,036,854,775,808个SHA1计算。这需要相当于6,500年单CPU计算和110年单GPU计算的处理能力。b /会伪造一个文件（使用相同的SHA1），但是使用附加约束，其内容和大小会产生相同的SHA1（单独内容上的冲突是不够的）：请参阅“ 如何计算git哈希？ ”）：blob SHA1基于内容和大小计算。有关更多信息，请参阅Valerie Anita Aurora的 “ 加密哈希函数的生命周期 ” 。 在那页中，她指出：谷歌花了6500个CPU年和110个GPU年来说服每个人我们需要停止使用SHA-1来处理安全关键应用程序。还因为它很酷查看更多在我下面的单独的答案。

Git如何处理blob上的SHA-1冲突？

3回答