Git中的签名功能是用来做什么的？

Question

Git中的签名功能有什么作用？

git commit --signoff

如果需要的话，什么时候应该使用它？

- Clark Gaebel

Answer 1

签名是进入Linux内核和其他一些项目的补丁所需的要求，但大多数项目实际上并不使用它。

它是在SCO诉讼（以及来自SCO的其他版权侵权指控，其中大部分他们实际上没有起诉）之后引入的，作为开发者原创证书。它用于说明您证明了您创建了相关的补丁，或者您证明您最好的知识是它是在适当的开源许可证下创建的，或者它已经由其他人根据这些条款提供给您。这可以帮助建立一个负责任地管理有关代码的版权状态的人员链，以确保未在适当的免费软件（开源）许可证下发布的受版权保护的代码不包含在内核中。

- Brian Campbell

---

需要注意的是，所描述的含义是由Linux内核项目（以及Git项目本身）分配给“Signed-off-by:”提交消息行的含义。然而，对于其他项目来说，这些行是没有意义的，除非该项目为它们分配了含义（例如通过在项目文档中描述它们；例如Linux的SubmittingPatches或Git的SubmittingPatches）。 - Chris Johnsen

为什么需要在提交信息中进行这个操作？我以为提交有一个作者附着在其上，并且它们是SHA1哈希的一部分。 - Leif Andersen

@Leif Mere，作者信息不足。我可能编写了一个补丁，但是如果我基于Unix的某些代码，我就没有权限在GPL下发布它（至少需要高级别人员的确认）。或者，补丁可能会在几个不同的维护者之间传递，然后才进入内核树；签名表示所有人的联系方式。阅读我提供的证明原点证书；当您添加签名行时，这就是它的含义。 "作者"标题可能不准确，并不一定意味着与证明原点中的所有内容都同意。 - Brian Campbell

没有 PGP 密钥，如何确定签名是真实的？ - HRJ

@HRJ，“已签署”的真实性实际上由您（提交者）来确定，而不是作者或已签署本身。如果以后有人（主要是已签署者）争议其无效性，最好拥有一封电子邮件或其他证明他同意的证据。如果blob未经GPG签名，提交者可能会说他没有提交此类blob（在我看来这是一个薄弱的辩护，但是...）。 在这种情况下，提交者可以使用-S功能来关闭循环。现在，通过使用-S和-s，您可以基于提交者的话建立一条责任链，即某个作者编写的代码已获得某个高层已签署者的授权使用。 - DrBeco

Answer 2

签名是提交信息末尾的一行，用于证明提交的作者身份。 其主要目的是提高跟踪谁做了什么的能力，特别是对于补丁。

示例提交：

Add tests for the payment processor.

Signed-off-by: Humpty Dumpty <[e-mail]>

如果用于开源项目，则应包含用户真实姓名。

如果分支维护者需要稍微修改补丁才能合并它们，他可以要求提交者重新调整，但这会适得其反。他可以调整代码并在结尾处加上自己的签名，这样原始作者仍然可以获得补丁的功劳。

Add tests for the payment processor.

Signed-off-by: Humpty Dumpty <[e-mail]>

[Project Maintainer: Renamed test methods according to naming convention.]
Signed-off-by: Project Maintainer <[e-mail]>

来源: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

- Andrzej Rehmann

---

在 git 提交中，author 字段和 committer 字段的存在是为了避免信息冗余。作者字段表示代码补丁的编写者，提交者字段则代表应用和推送该补丁的人。 - Leif Gruenwoldt

"certify" 是否能真正确认某次提交的作者？我的意思是，它是否像 -S（--gpg-sign）一样可靠，因为我认为不是这样。我想任何人都可以添加一个带有任何名称和电子邮件地址的“Signed-off-by”行，而 GPG 签名则更加可靠，但也许我错了。 - hdl

“Sign-off”是提交信息末尾的一行，用于证明该提交的作者是谁。它的主要目的是改进跟踪谁做了什么，特别是对于补丁 (patches) 的情况。但是这个句子几乎肯定是错误的（尤其是第一句）。可以看一个反例[b2c150d3aa]（链接在VonC的回答中），其中有两个Signed-off-by头文件；一个是由作者签名的，另一个则是由维护者签名的。这在Git和Linux项目中是常见做法。 - Guildenstern

继续上一个评论。签署意味着您在特定条件下编写了提交，或者您正在传递由已经努力实现上述条件的某人编写的内容。因此，它形成了一种认证链。 - Guildenstern

关于上面的更新：事实证明，在我上次回复中，我漏掉了一些东西，因此低估了这个答案。作者在“调整代码”方面部分正确，但对“签名”尾随部分强调有误。文档说明应添加括号尾随部分（如答案中的示例）来通知相关信息。因此，签名与此同时可用于由集成器/维护者等人员添加小更改。但是，签名仍然主要用作我所描述的内容。 - Guildenstern

对于我所见过的大多数项目，提交者被理解为“按下我批准、合并此请求”的人，并不表示提交者已经对提交进行了更改。一个可能的替代方案是在提交后添加另一个提交，其中提交者是作者，但如果第一个提交破坏了构建，则这可能是不可接受的，这将破坏二分法。 - Ciro Santilli OurBigBook.com

Answer 3

TLDR; 通常证明提交者有权在相同的许可下提交此作品，并同意开发者原点证书 (有关详细信息，请参见http://developercertificate.org/)。

---

Git 2.7.1 (2016年2月) 澄清了在提交 b2c150d (2016年1月5日) 由 David A. Wheeler (david-a-wheeler) 所做的更改。
^{(由Junio C Hamano -- gitster --于2016年2月5日合并至提交 7aae9ba)}

git commit手册页现在包含：

-s::
--signoff::

在提交日志信息的结尾添加提交者的 Signed-off-by 行。
Signed-off-by 的意义取决于项目，但它通常证明提交者有权以相同的许可证提交此工作并同意开发人员原产地证书（有关更多信息，请参见 https://developercertificate.org）。

---

扩展描述“--signoff”的文档。

修改各种文档（man页面）文件，以更详细地解释“--signoff”的含义。

这是由lwn article 'Bottomley: A modest proposal on the DCO'（开发人员证书）启发的，其中paulj指出：

“我对DCO的问题在于，即使将“-s”参数添加到git commit中也并不意味着您真正了解DCO（git commit手册中根本没有提到DCO），更不用说实际看到过它了。”

扩展git的文档将使得更容易争论开发者在使用“--signoff”时是否理解其含义。

---

请注意，现在（适用于Git 2.15.x/2.16，2018年第一季度）此签名已经可以应用于git pull命令。

请参见提交记录3a4d2c7 （作者：W. Trevor King (wking)，于2017年10月12日）。
^{（由Junio C Hamano -- gitster --合并入提交记录fb4cd88，于2017年11月6日）}

pull命令：向"git merge"传递--signoff/--no-signoff

合并可以使用--signoff，但是如果没有在pull中传递--signoff，使用起来会很不方便；允许'pull'使用这个选项并将其传递下去。

---

在 Git 2.33（2021 年第三季度）中，SubmitingPatches 文档进一步阐明了 signoff 的意图：DCO ( 对于开源项目而言，优先使用 DCO 而非 CLAs)。

查看提交 f003a91，提交 4523dc8（2021年7月22日）由Ævar Arnfjörð Bjarmason (avar)完成。
^{（由Junio C Hamano -- gitster --合并于提交 58705b4，2021年8月4日）}

提交补丁：将Signed-off-by的讨论移到"send"之上

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

将讨论添加SOB拖车的部分移到讨论生成补丁本身的部分之上。
这样做是有道理的，因为我们不希望有人在经历了"git format-patch"^(man)的过程后才意识到他们应该使用"git commit -s"^(man)或相应的方法。

提交补丁现在包含在其 手册页面中:

[[签名]]

通过添加您的Signed-off-by标记证明您的工作

为了改善跟踪谁做了什么，我们要求您认证您编写了补丁或有权根据相同许可证将其传递，方法是“签署”您的补丁。如果没有签署，则无法接受您的补丁。

仅当您认证以下 D-C-O 时：

[[dco]]

.开发者证书原点 1.1

---

请注意，GitHub 可能会强制要求您（自2022年6月起）向提交信息添加签署：

管理员可以要求在基于Web的提交上签名

组织所有者和存储库管理员现在可以要求开发人员在GitHub的Web界面上进行提交时进行签名，例如编辑文件或合并拉取请求。

此外，现在开发人员可以更轻松地在Web界面中完成签名，从而减少阻止合并的提交数量，并减少解决阻止提交所花费的时间。

启用该设置后，Web界面将通知开发人员他们的提交行为也构成了签名，如下所示。
与在命令行上使用Git的--signoff选项一样，在Web界面中签名将自动将Signed-off-by:文本附加到提交消息中。

- VonC

---

即使git提交文档（最终）提到了-s参数意图表示知情和同意/赞成/???的文件，我认为SOB在法律上非常薄弱。我认为至少Linus发明了SOB来解决社交问题，因为其他人正在倡导高开销的官僚主义。Linus什么都不想要，但他想出了这个方法来让他们闭嘴。据我所知，律师不会建议你对它投入太多的信任，如果有的话。 （我在LWN上是“paulj”）。 - paulj

VonC，你真是一个Git的资深专家。像这样的问题，你总是回答得非常明确、详尽，并且交叉引用得很好 - 追溯Git的发展历程，最终落地于用户使用的工具和文档。因此，感谢你的付出。 - Guildenstern

Answer 4

这个问题已经有了一些好的答案，我将尝试添加更广泛的回答，即关于当前实践中这些类型的行/标头/尾部是关于什么的。不是特别关于签名头（它不是唯一的）。

标头或尾部（↑1），如“sign-off”（↑2），在像Git和Linux这样的项目中，实际上是提交的结构化元数据。所有这些都附加在提交消息的末尾，在消息正文的“自由格式”（非结构化）部分之后。这些通常是token-value（或key-value）对，由冒号和空格（:␣）分隔。

就像我提到的，“sign-off”不是当前实践中唯一的尾部。例如，请参见与“Dirty Cow”有关的此提交：

 mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
 This is an ancient bug that was actually attempted to be fixed once
 (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
 get_user_pages() race for write access") but that was then undone due to
 problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

 In the meantime, the s390 situation has long been fixed, and we can now
 fix it by checking the pte_dirty() bit properly (and do it better).  The
 s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
 software dirty bits") which made it into v3.9.  Earlier kernels will
 have to look at the page state itself.

 Also, the VM has become more scalable, and what used a purely
 theoretical race back then has become easier to trigger.

 To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
 we already did a COW" rather than play racy games with FOLL_WRITE that
 is very fundamental, and then use the pte dirty flag to validate that
 the FOLL_COW flag is still valid.

 Reported-and-tested-by: Phil "not Paul" Oester <[e-mail]>
 Acked-by: Hugh Dickins <[e-mail]>
 Reviewed-by: Michal Hocko <[e-mail]>
 Cc: Andy Lutomirski <[e-mail]>
 Cc: Kees Cook <[e-mail]>
 Cc: Oleg Nesterov <[e-mail]>
 Cc: Willy Tarreau <[e-mail]>
 Cc: Nick Piggin <[e-mail]>
 Cc: Greg Thelen <[e-mail]>
 Cc: [e-mail]
 Signed-off-by: Linus Torvalds <[e-mail]>

除了上述“签名”尾随语之外，还有：

• “Cc”（已通知有关修补程序）
• “Acked-by”（代码所有者已确认，“看起来不错”）
• “Reviewed-by”（已审核）
• “Reported-and-tested-by”（报告并测试问题（我猜测））

其他项目（例如Gerrit）有其自己的标题和相关含义。

参见：https://git.wiki.kernel.org/index.php/CommitMessageConventions

故事寓意

我个人认为，尽管此特定元数据的初始动机是一些法律问题（根据其他答案），但这种元数据的实践已经超出了仅处理形成作者链的情况。

[↑1]：man git-interpret-trailers
[↑2]：它们有时也被称为“s-o-b”（首字母缩写），似乎是这样。

- Guildenstern