blocks|key|580313|text|如果两个文件在git中有相同的散列和，它会将这两个文件视为相同。在这种绝对不可能发生的情况下，你总是可以返回一次提交，并在文件中更改一些东西，这样它们就不会再发生冲突了……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|580314|参见Linus+Torvalds'+post+in+the+thread+“Starting+to+think+about+sha-256?”+in+the+git+mailing+list。|offset|length|580315|entityMap|0|LINK|mutability|MUTABLE|url|http://web.archive.org/web/20120701221418/http://kerneltrap.org/mailarchive/git/2006/8/28/211065^0|0|2|2L|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

If two files have the same hash sum in git, it would treat those files as identical. In the absolutely unlikely case this happens, you could always go back one commit, and change something in the file so they wouldn't collide anymore ...

See <a href="http://web.archive.org/web/20120701221418/http://kerneltrap.org/mailarchive/git/2006/8/28/211065" rel="noreferrer">Linus Torvalds' post in the thread “Starting to think about sha-256?” in the git mailing list</a>.

blocks|key|364606|text|在不解释为什么它不是问题的情况下，用正确的“但是”来回答这个问题是不可能的。如果不能很好地掌握哈希的真正含义，就不可能做到这一点。它比您可能在CS程序中接触到的简单情况要复杂得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364607|这里有一个对信息论的基本误解。如果您通过丢弃一些量(即，散列)将存在与数据长度直接相关的冲突的机会。数据越短，发生这种情况的可能性越小。现在，绝大多数冲突将是胡言乱语，使得它们更有可能实际发生(您永远不会在gibberish...even中检入二进制映像是某种结构化的)。最终，这种可能性微乎其微。为了回答你的问题，是的，git会将它们视为相同的，改变散列算法不会有什么帮助，它将采取某种形式的“第二次检查”，但最终，你将需要与数据长度一样多的“额外检查”数据以100%25+sure...keep记住你将99.99999....to一个非常长的位数……当然，就像你描述的那样，只需简单的检查即可。SHA-x是加密的强散列，这意味着通常不难故意创建两个彼此非常相似的源数据集，并且具有相同的散列。数据中的一个比特变化应该在哈希输出中产生不止一个比特的变化(最好是尽可能多的)，这也意味着从哈希到整个冲突集的恢复非常困难(但也不是完全不可能)，从而从这组冲突中提取出原始消息-除了少数几个之外，所有这些都是胡言乱语，而在那些没有胡言乱语的情况下，如果消息长度是任何重要长度，仍然有大量的数据需要筛选。加密散列的缺点是它们对一般的compute...in很慢。|364608|那么，这一切对Git意味着什么呢？不是很多。哈希很少被完成(相对于其他任何东西)，以至于它们的计算代价总体上对操作来说很低。命中一对碰撞的机会是如此之低，这不是一个现实的机会发生而不是立即被检测到(即。您的代码很可能会突然停止构建)，允许用户修复问题(备份修订，并再次进行更改，您几乎肯定会得到一个不同的哈希，因为时间更改，这也提供了git中的哈希)。如果你在git中存储任意二进制文件，这对你来说更有可能是一个真正的问题，这并不是它的主要使用模型。如果你想这样做……你最好使用传统的数据库。|364609|思考这一点并没有错--这是一个很好的问题，很多人只是冒充“不太可能，所以不值得考虑”--但它实际上要比这复杂一点。如果它真的发生了，它应该很容易被检测到，它不会是正常工作流程中的无声损坏。|364610|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It's not really possible to answer this question with the right "but" without also explaining why it's not a problem. It's not possible to do that without really having a good grip on what a hash really is. It's more complicated than the simple cases you might have been exposed to in a CS program.

There is a basic misunderstanding of information theory here. If you reduce a large amount of information into a smaller amount by discarding some amount (ie. a hash) there will be a chance of collision directly related to the length of the data. The shorter the data, the LESS likely it will be. Now, the vast majority of the collisions will be gibberish, making them that much more likely to actually happen (you would never check in gibberish...even a binary image is somewhat structured). In the end, the chances are remote. To answer your question, yes, git will treat them as the same, changing the hash algorithm won't help, it'll take a "second check" of some sort, but ultimately, you would need as much "additional check" data as the length of the data to be 100% sure...keep in mind you would be 99.99999....to a really long number of digits.... sure with a simple check like you describe. SHA-x are cryptographically strong hashes, which means is't generally hard to intentionally create two source data sets that are both VERY SIMILAR to each other, and have the same hash. One bit of change in the data should create more than one (preferably as many as possible) bits of change in the hash output, which also means it's very difficult (but not quite impossible) to work back from the hash to the complete set of collisions, and thereby pull out the original message from that set of collisions - all but a few will be gibberish, and of the ones that aren't there's still a huge number to sift through if the message length is any significant length. The downside of a crypto hash is that they are slow to compute...in general.

So, what's it all mean then for Git? Not much. The hashes get done so rarely (relative to everything else) that their computational penalty is low overall to operations. The chances of hitting a pair of collisions is so low, it's not a realistic chance to occur and not be detected immediately (ie. your code would most likely suddenly stop building), allowing the user to fix the problem (back up a revision, and make the change again, and you'll almost certainly get a different hash because of the time change, which also feeds the hash in git). There is more likely for it to be a real problem for you if you're storing arbitrary binaries in git, which isn't really what it's primary use model is. If you want to do that...you're probably better off using a traditional database.

It's not wrong to think about this - it's a good question that a lot of people just pass off as "so unlikely it's not worth thinking about" - but it's really a little more complicated than that. If it DOES happen, it should be very readily detectible, it won't be a silent corruption in a normal workflow.

blocks|key|364665|text|谷歌现在声称，在某些前提条件下，SHA-1碰撞是可能的：https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|364666|由于git使用SHA-1来检查文件完整性，这意味着git中的文件完整性受到了损害。|364667|当然，git应该使用更好的散列算法，因为现在有可能发生故意的冲突。|364668|entityMap|0|LINK|mutability|MUTABLE|url|https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html^0|S|24|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

Google now claims that SHA-1 collision is possible under certain preconditions:
<a href="https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html" rel="noreferrer">https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html</a>

Since git uses SHA-1 to check for file integrity, this means that file integrity in git is compromised.

IMO, git should definitely use a better hashing algorithm since deliberate collision is now possible.

blocks|key|364683|text|好吧，我猜我们现在知道会发生什么了--你应该预料到你的存储库会被破坏(source)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|364684|entityMap|0|LINK|mutability|MUTABLE|url|https://arstechnica.co.uk/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/^0|Z|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Well I guess we now know what would happen - you should expect that your repository would become corrupted (<a href="https://arstechnica.co.uk/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/" rel="nofollow noreferrer">source</a>).

What would actually happen if I had a hash collision while using git?

E.g. I manage to commit two files with the same sha1 checksum,
would git notice it or corrupt one of the files?

Could git be improved to live with that, or would I have to change to a new hash algorithm?

(Please do not deflect this question by discussing how unlikely that is - Thanks)

Hash collision in git

数据库

如果我在使用git时发生哈希冲突，实际会发生什么？例如，我用相同的sha1校验和提交了两个文件，git会注意到它或损坏其中一个文件吗？git是否可以改进以适应这种情况，或者我是否必须更改为新的散列算法？(请不要通过讨论这有多不可能来回避这个问题-谢谢)

问git中的散列冲突
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问git中的散列冲突EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问git中的散列冲突
EN