3

我最近了解了已签名的提交,并且推荐使用它们。我们可以使用 . 在本地签署提交git commit -S。之后我阅读了 git 手册页,有一个名为-s(used as git commit -s) 的选项,它说该选项签署了提交。当我查找时,-S它说它使用 GPG 密钥签署了提交。

我正在 GitHub 中使用 GPG 密钥设置签名提交。这在推送时会有所不同还是在推送到远程时是否相同?

4

2 回答 2

4

的实际描述-s/--signoff是:

在提交日志消息的末尾添加由提交者签名的行。signoff 的含义取决于项目,但它通常证明提交者有权在相同的许可下提交此作品并同意开发者原产地证书(有关更多信息,请参见http://developercertificate.org/)。

如上所述,它基本上在提交消息的末尾添加了一个“Signed-off-by:”行,如下所示:

$ git log
commit 172ccc467d2171b645bb55d51146af82ac36d356 (HEAD -> master)
Author: gino <my@email.com>
Date:   Sun Nov 15 11:56:10 2020 +0900

    Added something
    
    Signed-off-by: gino <my@email.com>

您可以将其理解为“我批准了提交并对此负责”。它的目的在这篇相关文章中已经得到了很好的回答:Git 中的 Sign Off 功能是干什么用的?. 它主要是一种基于项目特定的向提交分配责任的方式,正如该帖子中公认的答案所提到的,当提交的版权或许可相关时,这是必需的。

但由于它只是提交消息的一部分,任何人都可以添加/编辑它,实际上您可以通过手动输入或使用提交消息模板自己添加它。你甚至可以把别人的名字/电子邮件放在那里。在 Github 上, 它将被视为与任何其他多行提交消息相同的方式

在此处输入图像描述

...并且 Github 不会根据签核行验证提交或显示“此提交已被批准”的任何 UI 指示符。这当然违反了作为签核目的的 DCO,并且您可以使用插件/机器人来为 PR 强制执行它,例如这个probot/dco

-S/--gpg-sign另一方面,该选项是一个实际的加密签名,因为它使用在提交机器上生成的GPG 密钥,然后 Github 使用提供公钥来验证提交确实来自(或来自拥有您的 GPG 密钥的来源)。正如Github 关于签署提交的文档所说:

使用 GPG 或 S/MIME,您可以在本地签署标签和提交。这些标签或提交在 GitHub 上被标记为已验证,因此其他人可以相信更改来自受信任的来源。

如果提交或标签具有无法验证的签名,GitHub 会将提交或标签标记为未验证。

存储库管理员可以在分支上强制执行所需的提交签名,以阻止所有未签名和验证的提交。

使用 Github 签名-S并正确验证的提交将显示“已验证”指示器:

在此处输入图像描述

确保按照他们关于GPG 提交签名验证的步骤进行操作。Github 将使用它来:

在验证签名时,我们提取签名并尝试解析其 key-id。我们将 key-id 与上传到 GitHub 的密钥进行匹配。在您将 GPG 密钥上传到 GitHub 之前,我们无法验证您的签名。


至于使用哪一个,这取决于你在 Github 上放了什么以及你“签署提交”的目的是什么。我想说,如果您只是想表明实际上是(或您的一台机器/机器人)推动了该提交,那么使用 GPG 密钥签名更有意义。

于 2020-11-15T03:19:34.973 回答
2

-S(简称--gpg-sign)使用 gnupg 签署您的提交,并为其添加 PGP 签名。这是一个加密签名,证明 gpg 密钥的所有者或有权访问它的参与者正在提交/标记

-s(缩写)在提交消息的末尾--signoff添加“ ”。Signed-off-by: Username<Email>任何人都可以将此字符串放在提交消息中(因此它不能保证作者身份),但它已被用于维护版权。一些项目需要DCO “开发者原产地证书”——本质上是开发者已经证明他们有权贡献代码的证明

于 2020-11-15T02:18:52.610 回答