提交签名解决了什么问题或威胁?

jww*_*jww 10 git sign git-commit

我们使用GitHub,我们有一个执行提交签名的请求.在研究了这个过程之后,我不清楚提交签名解决了什么问题.据我了解这个过程,有一个"本地源代码"被提交到一个"本地仓库",被推送到"远程仓库".因此,有三个框和两个箭头创建从本地源文件到远程存储库的有向图.对于最终用户,流程是相反的.

在所描述的模型中,似乎我们希望授权在推送到远程仓库时发生; 并且提交签约几乎没有任何好处.

Git SCM手册,7.4 Git工具 - 签署您的工作并未说明它正在解决的问题.但它确实告诉我要寻找答案:

每个人都必须签名

签名标签和提交很棒,但如果您决定在正常工作流程中使用此标记,则必须确保团队中的每个人都了解如何执行此操作.如果你不这样做,你最终会花费大量时间帮助人们弄清楚如何用签名版本重写他们的提交.在将此作为标准工作流程的一部分采用之前,请确保您了解GPG以及签名的好处.

我假设Git工程师已经模拟了Git工作流程.他们发现了一个问题(或问题),他们放置了"提交签名"安全控制来修复它.我想知道他们通过"提交签名"确定了哪些问题并解决了.

我认为发生的事情是人们将身份验证与授权或代码完整性混淆/混淆.不幸的是,尽管愿意这样做,但身份验证不是授权或代码完整性.

git提交签名解决了什么问题?

mer*_*011 30

提交签名解决的问题与数字签名文档解决的问题相同:验证其作者的问题.

由于只有作者拥有自己的私钥,因此只有他们可以自己签署提交.

如果我相信一个特定的陌生人并且他们签署了他们的提交,我可以信任他们的代码,而不必亲自验证每一行.


考虑一下有人在github上分叉你的存储库,然后添加了一堆提交代码的安全漏洞的提交.他们将这些提交author name, author email, commit name, commit email设置为原始作者之一.

如果没有提交签名,则无法验证它们不是原始作者.

使用提交签名,这些伪造的提交无法签名,因为伪造者没有作者的私钥.

  • 同样,签署标签(特别是在剪切版本时)是*可验证的*表示该点由人们信任的人标记,以便他们可以确定该版本已获批准. (5认同)
  • “如果我信任特定的提交者并且他们已经签署了提交,那么我可以信任他们的代码而不必手动验证每一行。” -GPG签名并没有消除对代码审查的需要:)实际上,我想说的是,您可以相信,这实际上是提交者提交的代码,而不是其他人。 (3认同)
  • @jww,这是一个准确的总结,是的.由于您的库包含加密工具,它也可能使使用您的工具的密码学家感觉更舒服,因为他们至少有机会验证提交的作者身份. (2认同)