没有矛盾。Linus 本人在同一次演讲中说：

如果我有这 20 个字节，我可以从一个完全不受信任的来源下载一个 git 存储库，我可以保证他们没有对它做任何坏事。

我将“Git 使用 SHA-1 不是为了安全”解释为“出于安全原因，尚未将 SHA-1 添加到 git，但出于可靠性原因，但安全性仍然是一个很好的副作用”，以及“安全性零件在其他地方”，因为“最终验证由 gpg 完成，并且git verify-tag”。

Git 提交 ID 并不比“裸”SHA-1“更安全”。但是，与大多数其他 SHA-1 用例相比，使用 git 的用例更能抵抗碰撞攻击。

例如，证书中的 SHA-1 是危险的。有人可以为不同的域名创建两个具有相同哈希的证书。一个（“合法的”）在 CSR 中发送到 CA，另一个保持私有，直到用于具有 CA 签名的某些受害者。对于碰撞攻击，如果攻击者在某个位置更改原像（如证书的域名字段），他们也必须在另一个位置更改它。虽然攻击者可以自由选择这两个域名，但其他更改大多是固定的。特别是，它们是二进制的，不能成为证书的任何人类可读部分的一部分。一些攻击将它们隐藏在证书的公钥/私钥中（MD5 的讨论）。

然而，Git 主要用于源代码。在人类审查的 ASCII 差异中隐藏您的 {chosen-prefix,} 冲突要困难得多。2ff5e当您对提交中添加的文件的十六进制地址进行 if 条件时，维护人员通常会提出问题logo.png。总而言之，在提交中隐藏后门比攻击 SHA-1 更容易。

签名的 git 标签只是一个签名的 SHA1 校验和。很简单地说，每个 git 提交都是前一次提交的 SHA1 校验和（其中还包含其前一次提交的 SHA1，其中还包含其前一次提交的 SHA1 校验和等等......）。

如果您找到一种方法，如何更改存储库中的某些内容，保持 SHA1 不变（您发现冲突），那么您可以破坏签名。

请记住，git 是分布式 VCS。通常，有很多人拥有自己的克隆人。如果有问题，它会很快被发现。

此外，发现碰撞和发现特定碰撞之间存在很大差异。例如，很容易找到 2 个具有相同 MD5 和的“随机”不同数据。但是 AFAIK，如何稍微改变给定的数据并保持 MD5 不变仍然是一个难题，SHA1 比 MD5 强得多。

尽管如此，如果有人设法找到一种方法来轻松找到 SHA1 冲突，那么 git 就会遇到更大的问题。Git 使用 SHA1 作为每个对象的索引。如果您尝试提交 SHA1 碰撞对象，您可能会破坏（......我不确定......）至少提交。

以下是我的理解。

Git 通过 sha1 哈希识别几乎所有内容。您的签名标签通过它的 sha1 哈希来引用提交，提交通过它的 sha1 哈希来标识“树”，而“树”通过它们的 sha1 哈希来引用文件“blob”。

因此，如果您有两个由具有相同 sha1 哈希的“blob”表示的文件，那么您可以将一个替换为另一个，并且签名标签仍然可以正常验证。

对象的 git 散列在标头前面加上类型和大小，这意味着必须专门准备用于攻击 git 的冲突来攻击 git，但除此之外不会出现任何实际问题。

实际上，我认为风险在很大程度上取决于您在 git 存储库中保留的内容。我们没有针对 SHA1 的原像攻击，而且我们不太可能很快就会有。所以我们只需要担心碰撞攻击。

如果它是由人工审查者审查的人类可读源代码，那么风险很小。如果有人可以滑入一个无法解释的二进制垃圾块和一个基于该二进制垃圾块的内容做坏事的条件，他们可能会滑入恶意的东西，而不必担心 sha1 冲突。

OTOH 如果它被用于存储源自不受信任来源的二进制文件，则存在更多潜在问题。

“我们不太可能很快有时间” - 嗯。“攻击只会变得更好”。

原像攻击比碰撞攻击要困难得多。在 MD5 第一次碰撞被证明十年后，我们仍然没有可行的原像攻击。

我会更担心包含“jpeg + 无辜代码”和“jpeg + 邪恶代码”的两个提交

复杂性是由于 git 提交构建 jpeg 数据的方式，并且代码必须在同一个文件中。我想如果人们将 tarball 存储在他们的 git repo 或类似的东西中，这可能是一个问题。

另一种可能的情况是，如果某些代码根据自动文件类型检测决定如何处理文件。如果“明显选择的前缀”冲突变得可行，那么有人可能会提交一个看起来无害的二进制文件（一个图像左右），而该文件恰好在某个地方有一堆垃圾。然后用更危险的文件替换它。

与 md5 相比，从基本冲突到不同的选择前缀冲突大约需要 2 年时间。