【问题标题】:How does commit signing work?提交签名如何工作?
【发布时间】:2017-07-15 03:13:41
【问题描述】:

我目前想知道 git commit 签名是如何工作的。

试图找出这一点,但找不到任何确切的技术文档。我知道如何进行 git commit 签名,但我想知道 git 究竟做了什么来签署提交。

签名的具体内容是什么?它是给定提交时存储库内的完整数据,因此是提交消息等数据以及所有文件的数据吗?或者它只是带有指向所包含文件等的指针的提交?

【问题讨论】:

标签: git git-commit signing


【解决方案1】:

虽然它没有在任何地方记录,但对source code 的检查表明它是提交对象的全部内容。然后将这些内容修改为插入签名,因此验证过程必须将签名剥离到单独的缓冲区中,并将原始的、预签名插入的数据传递给 GPG 签名者。 p>

GPG 签名数据随后在计算提交的 SHA-1 校验和时发生,以成为提交的哈希 ID。分别参见gpg-interface.ccommit.c,函数sign_bufferdo_sign_commit。标签签名在builtin/tag.c(见函数do_sign及其调用者);签名标签的签名是附加的而不是插入的,但除此之外,它的工作方式几乎相同。

【讨论】:

  • 您在 SHA-1 演示的启发下提出的假设是正确的;)只是为了确保我正确理解了代码(我更多的是 Java,而不是 C 人)。只有包含对树的 SHA-1 引用的提交对象被签名。因此,如果我有一个签名的提交,我不能确定树是正确的,但只有签名者为具有相同哈希的树创建了一个提交?真是太可惜了……
  • @MarkusKreusch:是的,签名直接只保护提交或标签对象的内容。但是,提交和标记对象具有相当明显的形式(尽管允许包含任意文本),并且现有的用于击败 SHA-1 的技术留下了明显的痕迹。树对象有一个更受限制的形式:Git 可以(并且应该已经)很容易地检测到格式错误的树。只有 blob 对象才真正受到第二原像攻击。综上所述,如果 Git 可以开始使用 SHA-256 就好了,但过渡会相当艰难。
  • (另见stackoverflow.com/q/42433126/1256452 以及其中的邮件列表链接。)
  • 感谢您的链接。现在仔细查看了这篇论文,得出的结论是,在这种形式下,不可能使用它来为 git repo 中现有的“好”对象创建冲突。不过,很高兴看到 Git 使用 SHA-256。
  • Linus 关于 git 和 sha1 的声明:plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
【解决方案2】:

签名的是git cat-file(已删除签名)返回的原始提交对象。如果 HEAD 是签名提交,则可以手动验证签名如下:

git cat-file commit HEAD > signed-commit
grep -B 9999 'BEGIN PGP SIGNATURE-----' signed-commit | head -n -1 > signed-commit.stripped
grep -A 9999 'END PGP SIGNATURE-----' signed-commit | tail -n +2 >> signed-commit.stripped
sed 's/^gpgsig //' signed-commit | sed 's/^ //' > signed-commit.sig
gpg --verify signed-commit.sig signed-commit.stripped 

【讨论】:

猜你喜欢
  • 2014-05-04
  • 1970-01-01
  • 1970-01-01
  • 2020-12-13
  • 2020-09-05
  • 2012-02-22
  • 1970-01-01
  • 1970-01-01
  • 2011-12-11
相关资源
最近更新 更多