Git在遇到blob的SHA-1冲突时不会立即失败，而是可能导致数据丢失或混淆。在某些情况下，Git不会警告用户，而在其他情况下，它会停止操作并显示错误。Git的处理方式可能会让仓库变得损坏，克隆或拉取仓库的人可能会得到不同的内容。2017年后，随着SHA-1碰撞的实际示例出现，Git开始向SHA-256过渡，以增强安全性。
本文翻译自：How would Git handle a SHA-1 collision on a blob?
This probably never happened in the real-world yet, and may never happen, but let's consider this: say you have a git repository, make a commit, and get very very unlucky: one of the blobs ends up having the same SHA-1 as another that is already in your repository. 这可能永远不会发生在现实世界中，并且可能永远不会发生，但让我们考虑一下：假设您有一个git存储库，进行提交，并且变得非常不幸：其中一个blob最终拥有相同的SHA-1另一个已存在于您的存储库中。 Question is, how would Git handle this? 问题是，Git将如何处理这个？ Simply fail? 简直失败了？ Find a way to link the two blobs and check which one is needed according to the context? 找到一种方法来链接两个blob并根据上下文检查哪一个需要？
More a brain-teaser than an actual problem, but I found the issue interesting. 更多的是脑筋急转弯而非实际问题，但我发现这个问题很有趣。
#1楼
参考：https://stackoom.com/question/dPNl/Git如何处理blob上的SHA-冲突
#2楼
There are several different attack models for hashes like SHA-1, but the one usually discussed is collision search, including Marc Stevens' HashClash tool. 像SHA-1这样的哈希有几种不同的攻击模型，但通常讨论的是冲突搜索，包括Marc Stevens的HashClash工具。
"As of 2012, the most efficient attack against SHA-1 is considered to be the one by Marc Stevens[34] with an estimated cost of $2.77M to break a single hash value by renting CPU power from cloud servers." “截至2012年，针对SHA-1的最有效攻击被认为是Marc Stevens [34]的攻击，估计通过从云服务器租用CPU功率来破解单个哈希值的成本为277万美元。”
As folks pointed out, you could force a hash collision with git, but doing so won't overwrite the existing objects in another repository. 正如大家所指出的，你可以强制与git进行哈希冲突，但这样做不会覆盖另一个存储库中的现有对象。 I'd imagine even git push -f --no-thin won't overwrite the existing objects, but not 100% sure. 我想，即使是git push -f --no-thin也不会覆盖现有的对象，但不是100％肯定。
That said, if you hack into a remote repository then you could make your false object the older one there , possibly embedding hacked code into an open source project on github or similar. 也就是说，如果你攻入一个远程仓库，那么你可以让你的假对象上了年纪一个人也没有 ，可能是黑客嵌入代码到GitHub上或类似的一个开源项目。 If you were careful then maybe you could introduce a hacked version that new users downloaded. 如果你小心，那么也许你可以介绍新用户下载的黑客版本。
I suspect however that many things the project's developers might do could either expose or accidentally destroy your multi-million dollar hack. 但我怀疑项目开发人员可能做的很多事情可能会暴露或意外地破坏你的数百万美元的黑客攻击。 In particular, that's a lot of money down the drain if some developer, who you didn't hack, ever runs the aforementioned git push --no-thin after modifying the effected files, sometimes even without the --no-thin depending. 特别是，如果一些你没有攻击的开发人员在修改受影响的文件之后运行上述git push --no-thin ，有时即使没有--no-thin依赖，那也是很多钱。
#3楼
I did an experiment to find out exactly how Git would behave in this case. 我做了一个实验，以确切了解Git在这种情况下的表现。 This is with version 2.7.9~rc0+next.20151210 (Debian version). 这是版本2.7.9~rc0 + next.20151210（Debian版本）。 I basically just reduced the hash size from 160-bit to 4-bit by applying the following diff and rebuilding git: 我基本上只是通过应用以下diff和重建git将散列大小从160位减少到4位：
--- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
+++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
@@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
blk_SHA1_Update(ctx, padlen, 8);
/* Output hash */
- for (i = 0; i < 5; i++)
- put_be32(hashout + i * 4, ctx->H[i]);
+ for (i = 0; i < 1; i++)
+ put_be32(hashout + i * 4, (ctx->H[i] & 0xf000000));
+ for (i = 1; i < 5; i++)
+ put_be32(hashout + i * 4, 0);
}
Then I did a few commits and noticed the following. 然后我做了一些提交并注意到以下内容。
- If a blob already exists with the same hash, you will not get any warnings at all. 如果已经存在具有相同哈希的blob，则根本不会收到任何警告。 Everything seems to be ok, but when you push, someone clones, or you revert, you will lose the latest version (in line with what is explained above). 一切似乎都没问题，但当你推，有人克隆，或你还原，你将失去最新版本（符合上面解释的）。
- If a tree object already exists and you make a blob with the same hash: Everything will seem normal, until you either try to push or someone clones your repository. 如果树对象已经存在并且您使用相同的哈希创建一个blob：一切看起来都很正常，直到您尝试推送或某人克隆您的存储库。 Then you will see that the repo is corrupt. 然后你会看到回购是腐败的。
- If a commit object already exists and you make a blob with the same hash: same as #2 - corrupt 如果提交对象已经存在并且您使用相同的哈希创建一个blob：与＃2相同 - 损坏
- If a blob already exists and you make a commit object with the same hash, it will fail when updating the "ref". 如果blob已经存在并且您使用相同的哈希创建提交对象，则在更新“ref”时它将失败。
- If a blob already exists and you make a tree object with the same hash. 如果blob已经存在，并且您使用相同的哈希创建树对象。 It will fail when creating the commit. 创建提交时它将失败。
- If a tree object already exists and you make a commit object with the same hash, it will fail when updating the "ref". 如果树对象已经存在并且您使用相同的哈希创建提交对象，则在更新“ref”时它将失败。
- If a tree object already exists and you make a tree object with the same hash, everything will seem ok. 如果树对象已经存在并且您使用相同的哈希创建了一个树对象，那么一切都会好起来的。 But when you commit, all of the repository will reference the wrong tree. 但是当你提交时，所有的存储库都会引用错误的树。
- If a commit object already exists and you make a commit object with the same hash, everything will seem ok. 如果提交对象已经存在并且您使用相同的哈希创建提交对象，那么一切似乎都可以。 But when you commit, the commit will never be created, and the HEAD pointer will be moved to an old commit. 但是当你提交时，永远不会创建提交，并且HEAD指针将被移动到旧提交。
- If a commit object already exists and you make a tree object with the same hash, it will fail when creating the commit. 如果提交对象已存在并且您使用相同的哈希创建树对象，则在创建提交时它将失败。
For #2 you will typically get an error like this when you run "git push": 对于＃2，当你运行“git push”时，通常会出现这样的错误：
error: object 0400000000000000000000000000000000000000 is a tree, not a blob
fatal: bad blob object
error: failed to push some refs to origin
or: 要么：
error: unable to read sha1 file of file.txt (0400000000000000000000000000000000000000)
if you delete the file and then run "git checkout file.txt". 如果删除该文件，然后运行“git checkout file.txt”。
For #4 and #6, you will typically get an error like this: 对于＃4和＃6，您通常会收到如下错误：
error: Trying to write non-commit object
f000000000000000000000000000000000000000 to branch refs/heads/master
fatal: cannot update HEAD ref
when running "git commit". 在运行“git commit”时。 In this case you can typically just type "git commit" again since this will create a new hash (because of the changed timestamp) 在这种情况下，您通常只需再次键入“git commit”，因为这将创建一个新的哈希（因为更改了时间戳）
For #5 and #9, you will typically get an error like this: 对于＃5和＃9，您通常会收到如下错误：
fatal: 1000000000000000000000000000000000000000 is not a valid 'tree' object
when running "git commit" 当运行“git commit”时
If someone tries to clone your corrupt repository, they will typically see something like: 如果有人试图克隆您的损坏的存储库，他们通常会看到如下内容：
git clone (one repo with collided blob,
d000000000000000000000000000000000000000 is commit,
f000000000000000000000000000000000000000 is tree)
Cloning into 'clonedversion'...
done.
error: unable to read sha1 file of s (d000000000000000000000000000000000000000)
error: unable to read sha1 file of tullebukk
(f000000000000000000000000000000000000000)
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
What "worries" me is that in two cases (2,3) the repository becomes corrupt without any warnings, and in 3 cases (1,7,8), everything seems ok, but the repository content is different than what you expect it to be. 令我担心的是，在两种情况下（2,3）存储库在没有任何警告的情况下变得腐败，在3种情况下（1,7,8），一切似乎都没问题，但存储库内容与您期望的不同成为。 People cloning or pulling will have a different content than what you have. 克隆或拉动的人将拥有与您拥有的内容不同的内容。 The cases 4,5,6 and 9 are ok, since it will stop with an error. 情况4,5,6和9都可以，因为它会因错误而停止。 I suppose it would be better if it failed with an error at least in all cases. 我想如果它失败并且至少在所有情况下都出现错误会更好。
#4楼
To add to my previous answer from 2012 , there is now (Feb. 2017, five years later), an example of actual SHA-1 collision with shattered.io , where you can craft two colliding PDF files: that is obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file. 要添加到我之前的2012年答案 ，现在（2017年2月，五年后），与shattered.io发生实际SHA-1冲突的示例，您可以在其中制作两个碰撞的PDF文件：即获取SHA-第一个PDF文件上的1个数字签名，也可以作为第二个PDF文件上的有效签名被滥用。
See also " At death's door for years, widely used SHA1 function is now dead ", and this illustration . 另见“ 多年来在死亡之门，广泛使用的SHA1功能现已死亡 ”，并举例说明 。
Update 26 of February: Linus confirmed the following points in a Google+ post : 2月26日更新：Linus 在Google+帖子中确认了以下几点：
(1) First off - the sky isn't falling. （1）首先 - 天空没有下降。 There's a big difference between using a cryptographic hash for things like security signing, and using one for generating a "content identifier" for a content-addressable system like git. 使用加密哈希来进行安全签名，并使用一个为内容可寻址系统（如git）生成“内容标识符”之间存在很大差异。
(2) Secondly, the nature of this particular SHA1 attack means that it's actually pretty easy to mitigate against, and there's already been two sets of patches posted for that mitigation. （2）其次，这种特殊SHA1攻击的性质意味着它实际上很容易被缓解，并且已经发布了两组针对该缓解的补丁。
(3) And finally, there's actually a reasonably straightforward transition to some other hash that won't break the world - or even old git repositories. （3）最后，实际上有一个相当直接的转换到其他一些不会破坏世界的哈希 - 甚至是旧的git存储库。
Regarding that transition, see the Q1 2018 Git 2.16 adding a structure representing hash algorithm. 关于该转换，请参阅Q1 2018 Git 2.16，添加表示散列算法的结构。 The implementation of that transition has started. 该过渡的实施已经开始。
Starting Git 2.19 (Q3 2018) , Git has picked SHA-256 as NewHash , and is in the process of integrating it to the code (meaning SHA1 is still the default (Q2 2019, Git 2.21), but SHA2 will be the successor) 启动Git 2.19（ Q8 2018） ，Git已选择SHA-256作为NewHash ，并且正在将其集成到代码中（意味着SHA1仍然是默认值（Q2 2019，Git 2.21），但SHA2将成为继承者）
Original answer (25th of February) But: 原始答案（2月25日）但是：
- This allow to forge a blob, however the SHA-1 of the tree would still changes since the size of the forged blob might not be the same as the original one:see " How is the git hash calculated? "; 这允许伪造一个blob，但是树的SHA-1仍然会改变，因为伪造的blob的大小可能与原始blob的大小不同：请参阅“ 如何计算git哈希？ ”; a blob SHA1 is computed based on the content and size . blob SHA1基于内容和大小计算 。
It does have some issue forgit-svnthough . 它确实对git-svn有一些问题 。 Or rather with svn itself , as seen here . 或者更确切地说是svn本身 ，如此处所示 。 - As I mentioned in my original answer , the cost of such an attempt is still prohibitive for now (6,500 CPU years and 100 GPU years) See also Valerie Anita Aurora in " Lifetimes of cryptographic hash functions ". 正如我在原始答案中所提到的，此类尝试的成本目前仍然令人望而却步（6,500 CPU年和100 GPU年）另请参阅Valerie Anita Aurora的“ 加密散列函数的生命周期 ”。
- As commented before, this isn't about security or trust, but data integrity (de-duplication and error detection) which can be easily detected by a
git fsck, as mentioned by Linus Torvalds today. 如前所述，这不是关于安全性或信任，而是数据完整性（重复数据删除和错误检测），可以通过git fsck轻松检测到，正如Linus Torvalds今天所提到的那样。git fsckwould warn about a commit message with opaque data hidden after aNUL(althoughNULisn't always present in a fraudulent file ).git fsck会在NUL之后警告一条隐藏不透明数据的提交消息（尽管NUL并不总是存在于欺诈性文件中 ）。
Not everybody turns ontransfer.fsck, but GitHub does: any push would be will aborted in the case of a malformed object or a broken link. 并非每个人都打开transfer.fsck，但是GitHub会这样做：任何推送都会在格式错误的对象或链接断开的情况下中止。 Although... there is a reason this is not activated by default . 虽然...有一个原因，默认情况下不会激活它 。 - a pdf file can have arbitrary binary data that you can change to generate a colliding SHA-1, as opposed as forged source code. pdf文件可以包含任意二进制数据，您可以更改这些数据以生成冲突的SHA-1，而不是伪造的源代码。
The actual issue in creating two Git repositories with the same head commit hash and different contents. 创建两个具有相同头部提交哈希和不同内容的Git存储库的实际问题。 And even then, the attack remains convoluted . 即便如此， 攻击仍然令人费解 。 - Linus adds : Linus补充道 ：
The whole point of an SCM is that it isn't about a one-time event, but about continuous history. 一个SCM的整点是，它不是一次性的事件，而是连续的历史。 That also fundamentally means that a successful attack needs to work over time, and not be detectable. 这也从根本上意味着成功的攻击需要随着时间的推移而发挥作用，而且无法检测到。
If you can fool a SCM one time, insert your code, and it gets detected next week, you didn't actually do anything useful. 如果您可以欺骗SCM一次，插入您的代码，并在下周检测到它，您实际上没有做任何有用的事情。 You only burned yourself. 你只是烧了自己。
Joey Hess tries those pdf in a Git repo and he found : Joey Hess在Git回购中尝试这些pdf， 他发现 ：
That includes two files with the same SHA and size, which do get different blobs thanks to the way git prepends the header to the content. 这包括两个具有相同SHA和大小的文件，由于git将标头添加到内容的方式，它们可以获得不同的blob。
joey@darkstar:~/tmp/supercollider>sha1sum bad.pdf good.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65 bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1 good.pdf
While appending identical data to these colliding files does generate other collisions, prepending data does not. 虽然向这些冲突文件附加相同的数据确实会产生其他冲突，但是前置数据却没有。
So the main vector of attack (forging a commit) would be : 所以攻击的主要载体（伪造提交）将是 ：
- Generate a regular commit object; 生成常规提交对象;
- use the entire commit object + NUL as the chosen prefix, and 使用整个提交对象+ NUL作为选择的前缀，和
- use the identical-prefix collision attack to generate the colliding good/bad objects. 使用相同前缀冲突攻击来生成冲突的好/坏对象。
- ... and this is useless because the good and bad commit objects still point to the same tree! ...这是没用的，因为好的和坏的提交对象仍然指向同一棵树！
Plus, you already can and detect cryptanalytic collision attacks against SHA-1 present in each file with cr-marcstevens/sha1collisiondetection 此外，您已经可以使用cr-marcstevens/sha1collisiondetection检测每个文件中存在的SHA-1的密码分析碰撞攻击
Adding a similar check in Git itself would have some computation cost . 在Git中添加类似的检查会产生一些计算成本 。
On changing hash, Linux comments : 在更改哈希时， Linux评论 ：
The size of the hash and the choice of the hash algorithm are independent issues. 散列的大小和散列算法的选择是独立的问题。
What you'd probably do is switch to a 256-bit hash, use that internally and in the native git database, and then by default only show the hash as a 40-character hex string (kind of like how we already abbreviate things in many situations). 您可能要做的是切换到256位散列，在内部和本机git数据库中使用它，然后默认情况下只将散列显示为40个字符的十六进制字符串（有点像我们已经缩写的东西很多情况）。
That way tools around git don't even see the change unless passed in some special "--full-hash" argument (or "--abbrev=64" or whatever - the default being that we abbreviate to 40). 那样的git工具甚至看不到变化，除非传入一些特殊的“--full-hash”参数（或“--abbrev=64”或其他 - 默认是我们缩写为40）。
Still, a transition plan (from SHA1 to another hash function) would still be complex , but actively studied. 尽管如此， 过渡计划（从SHA1到另一个哈希函数）仍然很复杂 ，但需要积极研究。
A convert-to-object_id campaign is in progress : convert-to-object_id广告系列 正在进行中 ：
Update 20th of March: GitHub detail a possible attack and its protection : 3月20日更新： GitHub详细说明可能的攻击及其保护 ：
SHA-1 names can be assigned trust through various mechanisms. 可以通过各种机制为SHA-1名称分配信任。 For instance, Git allows you to cryptographically sign a commit or tag. 例如，Git允许您以加密方式对提交或标记进行签名。 Doing so signs only the commit or tag object itself, which in turn points to other objects containing the actual file data by using their SHA-1 names. 这样做只会签署提交或标记对象本身，而后者又通过使用SHA-1名称指向包含实际文件数据的其他对象。 A collision in those objects could produce a signature which appears valid, but which points to different data than the signer intended. 这些对象中的冲突可以产生看似有效的签名，但是指向与签名者意图不同的数据。 In such an attack the signer only sees one half of the collision, and the victim sees the other half. 在这样的攻击中，签名者只看到一半的碰撞，受害者看到另一半。
Protection: 保护：
The recent attack uses special techniques to exploit weaknesses in the SHA-1 algorithm that find a collision in much less time. 最近的攻击使用特殊技术来利用SHA-1算法中的弱点，这些弱点在更短的时间内发现了冲突。 These techniques leave a pattern in the bytes which can be detected when computing the SHA-1 of either half of a colliding pair. 这些技术在字节中留下了一个模式，在计算碰撞对的任何一半的SHA-1时可以检测到这种模式。
GitHub.com now performs this detection for each SHA-1 it computes, and aborts the operation if there is evidence that the object is half of a colliding pair. GitHub.com现在对它计算的每个SHA-1执行此检测，如果有证据表明该对象是碰撞对的一半，则中止该操作。 That prevents attackers from using GitHub to convince a project to accept the "innocent" half of their collision, as well as preventing them from hosting the malicious half. 这可以防止攻击者使用GitHub来说服项目接受他们碰撞的“无辜”一半，并阻止他们托管恶意的一半。
See " sha1collisiondetection " by Marc Stevens 参见Marc Stevens的 “ sha1collisiondetection ”
Again, with Q1 2018 Git 2.16 adding a structure representing hash algorithm, the implementation of a transition to a new hash has started. 同样，随着Q1 2018 Git 2.16添加表示散列算法的结构，已经开始实现向新散列的转换。
As mentioned above, the new supported Hash will be SHA-256 . 如上所述，新支持的Hash将是SHA-256 。
#5楼
According to Pro Git : 据Pro Git说 ：
If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. 如果你碰巧提交的哈希值与存储库中的前一个对象具有相同的SHA-1值，Git将会在Git数据库中看到前一个对象，并假设它已经被写入。 If you try to check out that object again at some point, you'll always get the data of the first object. 如果您尝试在某个时刻再次检出该对象，您将始终获得第一个对象的数据。
So it wouldn't fail, but it wouldn't save your new object either. 所以它不会失败，但它也不会保存你的新对象。
I don't know how that would look on the command line, but that would certainly be confusing. 我不知道命令行会怎么样，但这肯定会令人困惑。
A bit further down, that same reference attempts to illustrate the likely-ness of such a collision: 再往下一点，同样的参考试图说明这种碰撞的可能性：
Here's an example to give you an idea of what it would take to get a SHA-1 collision. 下面是一个示例，让您了解获取SHA-1冲突所需的内容。 If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. 如果地球上所有65亿人都在进行编程，而每一秒，每一个人都生成的代码相当于整个Linux内核历史（100万Git对象）并将其推入一个巨大的Git存储库，则需要5年时间该存储库包含足够的对象，以使单个SHA-1对象发生碰撞的概率为50％。 A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night. 更高的可能性是你的编程团队的每个成员都会在同一天晚上被无关紧要的事件中的狼袭击和杀死。
#6楼
Original answer (2012) (see shattered.io 2017 SHA1 collision below) 原始答案（2012）（见下面shattered.io 2017 SHA1碰撞）
That old (2006) answer from Linus might still be relevant: Linus的那个旧的（2006）答案可能仍然是相关的：
Nope. 不。 If it has the same SHA1, it means that when we receive the object from the other end, we will not overwrite the object we already have. 如果它具有相同的SHA1，则意味着当我们从另一端接收到对象时，我们将不会覆盖我们已有的对象。
So what happens is that if we ever see a collision, the "earlier" object in any particular repository will always end up overriding. 所以会发生的是，如果我们看到碰撞，任何特定存储库中的“早期”对象将始终最终覆盖。 But note that "earlier" is obviously per-repository, in the sense that the git object network generates a DAG that is not fully ordered, so while different repositories will agree about what is "earlier" in the case of direct ancestry, if the object came through separate and not directly related branches, two different repos may obviously have gotten the two objects in different order. 但请注意，“早期”显然是每个存储库，因为git对象网络生成的DAG不是完全有序的，因此虽然不同的存储库会同意直接祖先情况下的“早期”，如果对象来自分离而非直接相关的分支，两个不同的回购可能显然已经得到了不同顺序的两个对象。
However, the "earlier will override" is very much what you want from a security standpoint: remember that the git model is that you should primarily trust only your own repository. 但是，从安全角度来看，“早先将覆盖”非常符合您的要求：请记住，git模型是您应该主要只信任自己的存储库。
So if you do a "git pull", the new incoming objects are by definition less trustworthy than the objects you already have, and as such it would be wrong to allow a new object to replace an old one. 因此，如果你执行“git pull”，新的传入对象根据定义不如你已经拥有的对象值得信任，因此允许新对象替换旧对象是错误的。So you have two cases of collision: 所以你有两种碰撞案例：
the inadvertent kind , where you somehow are very very unlucky, and two files end up having the same SHA1. 无意中 ，你不知何故非常不走运，两个文件最终有相同的SHA1。
At that point, what happens is that when you commit that file (or do a "git-update-index" to move it into the index, but not committed yet), the SHA1 of the new contents will be computed, but since it matches an old object, a new object won't be created, and the commit-or-index ends up pointing to the old object . 此时，当您提交该文件（或执行“git-update-index”将其移入索引但尚未提交）时，将会计算新内容的SHA1，但由于它匹配旧对象，不会创建新对象，并且commit-or-index最终指向旧对象 。
You won't notice immediately (since the index will match the old object SHA1, and that means that something like "git diff" will use the checked-out copy), but if you ever do a tree-level diff (or you do a clone or pull, or force a checkout) you'll suddenly notice that that file has changed to something completely different than what you expected. 您不会立即注意到（因为索引将与旧对象SHA1匹配，这意味着像“git diff”这样的东西将使用签出的副本），但是如果你曾经做过树级差异（或者你做的话）克隆或拉，或强制结账）你会突然注意到该文件已经变成了与你期望的完全不同的东西。
So you would generally notice this kind of collision fairly quickly. 所以你通常会很快注意到这种碰撞。
In related news, the question is what to do about the inadvertent collision.. 在相关新闻中，问题是如何处理无意碰撞..
First off, let me remind people that the inadvertent kind of collision is really really really damn unlikely, so we'll quite likely never ever see it in the full history of the universe. 首先，让我提醒人们，那种不经意的碰撞是真的真的真的该死的可能性不大，因此我们很可能永远不会看到它在宇宙的整个历史。
But if it happens, it's not the end of the world: what you'd most likely have to do is just change the file that collided slightly, and just force a new commit with the changed contents (add a comment saying "/* This line added to avoid collision */") and then teach git about the magic SHA1 that has been shown to be dangerous. 但是如果它发生了，那就不是世界末日： 你最有可能要做的就是改变稍微相撞的文件，然后强制使用更改的内容进行新的提交 （添加评论说“/* This line added to avoid collision */“）然后教git关于已被证明是危险的魔法SHA1。
So over a couple of million years, maybe we'll have to add one or two "poisoned" SHA1 values to git. 因此，在几百万年中，我们可能必须向git添加一个或两个“中毒”SHA1值。 It's very unlikely to be a maintenance problem ;) 这不太可能成为维护问题;）The attacker kind of collision because somebody broke (or brute-forced) SHA1. 攻击者之所以发生碰撞，是因为有人破坏了（或暴力强迫）SHA1。
This one is clearly a lot more likely than the inadvertent kind, but by definition it's always a "remote" repository. 这其中显然有很多比无意样的可能性较大，但顾名思义它总是一个“远程”库。 If the attacker had access to the local repository, he'd have much easier ways to screw you up. 如果攻击者可以访问本地存储库，他就会有更容易的方法来阻止你。
So in this case, the collision is entirely a non-issue : you'll get a "bad" repository that is different from what the attacker intended, but since you'll never actually use his colliding object, it's literally no different from the attacker just not having found a collision at all , but just using the object you already had (ie it's 100% equivalent to the "trivial" collision of the identical file generating the same SHA1). 所以在这种情况下， 碰撞完全不是问题 ：你会得到一个与攻击者意图不同的“坏”存储库，但是因为你永远不会真正使用他的碰撞对象，所以它实际上与攻击者根本没有发现碰撞 ，只是使用你已经拥有的对象（即它100％相当于生成相同SHA1的相同文件的“平凡”碰撞）。
The question of using SHA-256 is regularly mentioned, but not act upon for now (2012). 经常提到使用SHA-256的问题 ，但现在不采取行动（2012）。
Note: starting 2018 and Git 2.19 , the code is being refactored to use SHA-256. 注意： 从2018和Git 2.19开始 ，代码被重构为使用SHA-256。
Note (Humor): you can force a commit to a particular SHA1 prefix , with the project gitbrute from Brad Fitzpatrick ( bradfitz ) . 注意（幽默）：您可以使用Brad Fitzpatrick（ bradfitz ）的项目gitbrute强制提交特定的SHA1 前缀 。
gitbrute brute-forces a pair of author+committer timestamps such that the resulting git commit has your desired prefix. gitbrute强制执行一对作者+提交者时间戳，以便生成的git commit具有您想要的前缀。
Example: https://github.com/bradfitz/deadbeef 示例： https ： //github.com/bradfitz/deadbeef
Daniel Dinnyes points out in the comments to 7.1 Git Tools - Revision Selection , which includes: Daniel Dinnyes 在 7.1 Git Tools - Revision Selection 的评论中指出，其中包括：
A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night. 更高的可能性是你的编程团队的每个成员都会在同一天晚上被无关紧要的事件中的狼袭击和杀死。
Even the more recently (February 2017) shattered.io demonstrated the possibility of forging a SHA1 collision: 即使最近（2017年2月） shattered.io证明了伪造SHA1碰撞的可能性：
(see much more in my separate answer , including Linus Torvalds' Google+ post) （请参阅我的单独答案中的更多内容，包括Linus Torvalds的Google+帖子）
- a/ still requires over 9,223,372,036,854,775,808 SHA1 computations. a /仍需要超过9,223,372,036,854,775,808个SHA1计算。 This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations. 这需要相当于6,500年单CPU计算和110年单GPU计算的处理能力。
- b/ would forge one file (with the same SHA1), but with the additional constraint its content and size would produce the identical SHA1 (a collision on the content alone is not enough): see " How is the git hash calculated? "): a blob SHA1 is computed based on the content and size . b /会伪造一个文件（使用相同的SHA1），但是使用附加约束，其内容和大小会产生相同的SHA1（单独内容上的冲突是不够的）：请参阅“ 如何计算git哈希？ ”） ： blob SHA1基于内容和大小计算 。
See " Lifetimes of cryptographic hash functions " from Valerie Anita Aurora for more. 有关更多信息，请参阅Valerie Anita Aurora的 “ 加密哈希函数的生命周期 ”。
In that page, she notes: 在那页中，她指出：
Google spent 6500 CPU years and 110 GPU years to convince everyone we need to stop using SHA-1 for security critical applications. 谷歌花了6500个CPU年和110个GPU年来说服每个人我们需要停止使用SHA-1来处理安全关键应用程序。
Also because it was cool 还因为它很酷
See more in my separate answer below . 请参阅下面的单独答案中的更多内容
扫一扫
314
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
