谷歌现在声称在某些前提条件下SHA-1碰撞是可能的: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

由于git使用SHA-1来检查文件完整性，这意味着git中的文件完整性受到了损害。

在我看来，git应该使用更好的哈希算法，因为故意碰撞现在是可能的。

git是否可以改进以适应这种情况，或者我必须更改为一个新的哈希算法?

任何哈希算法都有可能发生冲突，所以改变哈希函数并不能排除问题，它只是让它不太可能发生。所以你应该选择一个非常好的哈希函数(SHA-1已经是，但你要求不要被告知:)

如果两个文件在git中具有相同的哈希和，它会将这两个文件视为相同的。在绝对不可能发生这种情况的情况下，你可以总是返回一次提交，并更改文件中的某些内容，这样它们就不会再碰撞了……

请参阅Linus Torvalds的帖子“开始考虑sha-256?”的邮件列表。

你可以在“Git如何处理一个blob上的SHA-1碰撞?”中看到一个很好的研究。

由于SHA1冲突现在是可能的(正如我在回答中用shatat .io提到的)，Git 2.13(2017年第二季度)将通过Marc Stevens (CWI)和Dan Shumow(微软)实现的SHA-1“检测试图创建冲突”的变体来改善/缓解当前的情况。

参见Jeff King (peff)的commit f5f5e7f, commit 8325e43, commit c0c2006, commit 45a574e, commit 28dc98e(2017年3月16日)。 (由Junio C Hamano—gitster—在commit 48b3693中合并，2017年3月24日)

Makefile: make DC_SHA1 the default We used to use the SHA1 implementation from the OpenSSL library by default. As we are trying to be careful against collision attacks after the recent "shattered" announcement, switch the default to encourage people to use DC_SHA1 implementation instead. Those who want to use the implementation from OpenSSL can explicitly ask for it by OPENSSL_SHA1=YesPlease when running "make". We don't actually have a Git-object collision, so the best we can do is to run one of the shattered PDFs through test-sha1. This should trigger the collision check and die.

Git是否可以改进以适应这种情况，或者我是否必须改用新的哈希算法?

2017年12月Git 2.16(2018年第一季度)更新:支持替代SHA的努力正在进行中:参见“为什么Git不使用更现代的SHA?”。

您将能够使用另一种哈希算法:SHA1不再是Git的唯一算法。

Git 2.18(2018年第二季度)记录了这个过程。

参见Ævar Arnfjörð Bjarmason (avar)提交5988eb6，提交45fa195(2018年3月26日)。 (由Junio C Hamano - gitster -在commit d877975中合并，2018年4月11日)

doc hash-function-transition: clarify what SHAttered means Attempt to clarify what the SHAttered attack means in practice for Git. The previous version of the text made no mention whatsoever of Git already having a mitigation for this specific attack, which the SHAttered researchers claim will detect cryptanalytic collision attacks. I may have gotten some of the nuances wrong, but as far as I know this new text accurately summarizes the current situation with SHA-1 in git. I.e. git doesn't really use SHA-1 anymore, it uses Hardened-SHA-1 (they just so happen to produce the same outputs 99.99999999999...% of the time). Thus the previous text was incorrect in asserting that: [...]As a result [of SHAttered], SHA-1 cannot be considered cryptographically secure any more[...] That's not the case. We have a mitigation against SHAttered, however we consider it prudent to move to work towards a NewHash should future vulnerabilities in either SHA-1 or Hardened-SHA-1 emerge.

所以现在新的文档是这样的:

Git v2.13.0 and later subsequently moved to a hardened SHA-1 implementation by default, which isn't vulnerable to the SHAttered attack. Thus Git has in effect already migrated to a new hash that isn't SHA-1 and doesn't share its vulnerabilities, its new hash function just happens to produce exactly the same output for all known inputs, except two PDFs published by the SHAttered researchers, and the new implementation (written by those researchers) claims to detect future cryptanalytic collision attacks. Regardless, it's considered prudent to move past any variant of SHA-1 to a new hash. There's no guarantee that future attacks on SHA-1 won't be published in the future, and those attacks may not have viable mitigations. If SHA-1 and its variants were to be truly broken, Git's hash function could not be considered cryptographically secure any more. This would impact the communication of hash values because we could not trust that a given hash value represented the known good version of content that the speaker intended.

注意:现在同一文档(2018年第三季度，Git 2.19)明确地将“新哈希”引用为SHA-256:参见“为什么Git不使用更现代的SHA?”。

谷歌现在声称在某些前提条件下SHA-1碰撞是可能的: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

由于git使用SHA-1来检查文件完整性，这意味着git中的文件完整性受到了损害。

在我看来，git应该使用更好的哈希算法，因为故意碰撞现在是可能的。

好吧，我想我们现在知道会发生什么了——你应该预料到你的存储库会被损坏(源代码)。