git - 是否可以预先计算一个 git commit 哈希，以便可以将其放置在提交本身中？

Question

我正要从网站管理员中删除我不相信有人在使用的功能。但是，我想在有人仍在使用它的情况下留言。我打算用以下效果替换 HTML 模板：

<p>This feature has been disabled.  If you need it back please ask engineering to revert #1234567890abcdef<p>

显然，我意识到这可以通过两次提交轻松完成。但是，我认为从密码学的角度来看这是一个有趣的问题。

假设您只能修改散列本身，那么满足此属性的散列实际存在的可能性有多大？当您缩短哈希（因为 git 允许唯一前缀）时，可能会增加这种哈希的机会。6 字符前缀的概率是多少？找到它有多难？

Answer 1

该脚本对短哈希执行类似的操作。

假设（SHA-1）散列函数是均匀分布的（这是重点），计算概率很容易。这是一个示例 SHA-1 哈希：

0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33

40 个字符。每个字符 4 位。2^(number-of-characters * 4)可能性。

因此，如果您想要 SHA-1 的前 7 个半字节（十六进制字符），您正在查看2^(7*4)==1/268435456找到正确哈希的机会。（如您所见，这对于脚本来说应该不会太难！）

Answer 2

如果散列，你可以这样做：

1. 是短。只需尝试多次，直到满足该属性。n 位散列的成本为 2^n。SHA-1 的 160 位太长了，无法正常工作。您可以对哈希的前几位执行此操作。大约 8-12 个十六进制数字（32-48 位）应该是可行的，无需太多努力。
2. 哈希具有允许这样做的数学结构。CRC 和类似的哈希值是这样工作的。像 SHA-1 这样的典型加密哈希是不可能的。

简而言之，您不能拥有包含其自己的哈希的提交。

Answer 3

您可以git hash-object <fileName>查看这篇文章如何在没有 Git 的情况下将 Git SHA1 分配给文件？

虽然我不认为你想做的事情是可能的。编辑文件将更改文件的哈希值。因此，如果您计算哈希并将该值放入文件中，则文件的哈希现在已更改。因此，您保存在文件中的哈希不会是正确的哈希。