| LWN.net 需要您！ 没有订阅者，《生活周刊》将不复存在。 请考虑注册订阅，帮助 LWN 继续出版。 |
会议由Linux基金会（LF）负责kernel.org（还有其他职责）的康斯坦丁-里亚比采夫（Konstantin Ryabitsev）组织和领导。 他说，通过电子邮件发送补丁的方式开发内核是次优的，尤其是在与持续集成（CI）流程对接时，但对于许多内核开发人员来说，这种方式仍然很有效。 任何新流程都必须与旧流程共存，否则就不会被采用。 看起来，LF 有一些资源可以用于改进内核的开发流程，特别是如果这项工作显然是社区所希望的。
证明
Ryabitsev 的第一个目标在维护者峰会上并不突出，但却是他关注已久的问题：改进补丁的证明方式，以便接收者可以确定补丁的出处。 目前，补丁根本没有认证，因此接收者只能相信补丁来自名字出现在补丁上的开发者。 我们都认为维护者会仔细观察，并能捕捉到伪造的电子邮件，但事实是，恶意代码很容易从维护者手中溜走。 因此，攻击者完全有可能找到在内核中添加漏洞的方法。
因此，Ryabitsev 认为要解决的第一个问题就是修复签名问题。 他说，Linus Torvalds 会验证与拉取请求相关的签名标签，因此这部分流程已经得到了解决。 但实际补丁上并没有签名，如何添加签名也没有达成共识。
他的建议是在电子邮件补丁上也引入签名。 使用的机制将是minisign，而不是GnuPG；minisign 的一大优势是所附签名比 GnuPG 创建的签名短得多。 Steve Rostedt 这时插话质疑这种方法的价值；他说，要想攻击成功，就必须用模仿所谓作者的风格编写的相对复杂的补丁。 他说，这将是一项艰巨的任务；任何有能力的人都可以破解用于验证的加密方案。
但 Ryabitsev 回应说，迷你签名是 "真正的加密技术"，破解起来并不容易；比起破解加密，有更容易的方法把坏代码带入内核。 这种方案的难点在于身份跟踪。 GnuPG 和之前的 PGP 一样，都是基于 "信任网 "的理念，但多年来，信任网已被证明大多行不通，人们也逐渐放弃了它。 较新的方案（如 SSH）往往基于 "首次使用即信任"（或 TOFU）模式，即新密钥在首次使用时即被信任（并被记住），但密钥的更改则需要严格审查。 他建议在 Git 的认证机制中也使用 TOFU 方法。
拉斐尔-维索基（Rafael Wysocki）也持怀疑态度，他断言这种方案并不能解决问题，只是把问题转移到了别处。 他说，攻击者可以创建一个身份，并在提交恶意内容之前逐步建立信任；提议的方案增加了复杂性，但并没有真正解决任何问题。 Ryabitsev 不同意他的观点：建立信任需要时间和资源，但攻击者现在就可以欺骗受信任的开发者。
Frank Rowand 问，是否希望维护者在提交补丁之前去掉签名。 Ryabitsev 回答说，签名将位于更新日志中"----"行的下方，因此在提交时会自动剥离。 但所使用的密钥也会记入本地数据库，并在下一次出现来自同一开发人员的补丁时进行验证。 Rostedt 指出，一次性提交者在这个数据库中不会有密钥；Ryabitsev 回答说，由于这些开发者不会再回来，所以这并不重要。 这个计划的目的是信任正在进行的开发者。
他希望基于迷你签名的证明能成为 Git 的一部分；像git format-patch这样的工具就能自动添加迷你签名。 Rowand 指出，很多开发者使用的 Git 版本相对较老，因此需要数年时间才能向所有人推广这一功能。 他说，应该改用 GnuPG；开发者已经有了它，而且内核的信任网络已经存在。 但 Ryabitsev 说，GnuPG 并不是一个很好的补丁签名工具；附带的签名通常比补丁本身还要大，而列表归档机制往往会将其删除。 要真正发挥作用，补丁上的签名必须不引人注目。
与本次会议上讨论的许多问题一样，签名的使用将是选择性的，至少在最初是这样。 Ryabitsev 正在考虑编写一个机器人，它可以监视邮件列表，并温和地建议未使用签名的开发者开始使用签名。 他询问小组成员这个方案整体上是否是个好主意，几乎得到了所有人的同意（Rowand 是个例外）。 因此，他打算尝试在 Git 中添加所需的支持。
基础树信息
补丁提交者常问的一个问题是"这个补丁是针对哪棵树打的？ 要成功打上补丁，通常需要这些信息，而 CI 系统也需要这些信息才能进行自动测试。 但目前补丁中并不包含 "基础树信息"，而解决这个问题是许多开发者的愿望之一。 德米特里-维尤科夫（Dmitry Vyukov）问，是将这一功能添加到 Git 并等待其被采用，还是创建一个开发人员现在就能使用的封装脚本更好。 不过事实证明，--base选项现在就可以在 Git 中使用，只是需要让提交者使用它而已。 维尤科夫也认为这是最困难的部分；他建议创建一个能自动提供该选项的封装脚本。
会议还讨论了托瓦尔兹是否会抱怨基树信息的问题，就像他在补丁中出现Change-id等标签时一样。 不过，问题并不在于额外的标签，而是这些信息的无用性。 如果基础树信息有用，就不应该有抱怨。
有人指出，基础树信息可能并不总是对他人有帮助；例如，该基础可能在一棵私有树中。 但在其他时候，它可能确实有用。 Rostedt 指出，用于 x86（及更高版本）维护的 "提示 "树中有十几个分支；知道补丁适用于哪个分支会很有帮助。 大家似乎都同意应该提供这些信息，而且应该让checkpatch.pl脚本检查这些信息。 最终可能会有一个机器人来唠叨那些在补丁中忽略了这些信息的开发者，但必须注意防止它产生过多的噪音。
电子邮件之外
出于种种原因，要求所有内核补丁都通过电子邮件发送似乎是一项前途有限的政策。 不过，转而使用类似 GitHub 或 GitLab 的 "锻造 "服务是一个没有普遍吸引力的想法，尤其是在短期内。 但人们希望有一种解决方案，既能让一些开发人员摆脱电子邮件的束缚，又能在整体上保持当前的工作流程。 朝这个方向迈出的第一步很可能是某种 Git 到电子邮件的桥梁。 不过 Ryabitsev 指出，对于这样的桥梁应该是什么样子，目前还没有达成共识。
一种方案是开发人员可以推送到一个特殊的 Git 仓库；推送到该仓库的任何补丁系列都将转化为一系列电子邮件，并发送到相应的地址。 不过，Ryabitsev 并不喜欢这个想法；任何这样的系统都会成为一个中心故障点，可能会在不恰当的时候宕机。 另一个方案是某种网络服务，它可以指向一个公共存储库；同样，它将生成一系列电子邮件并提交。 不过，这种方案还有一个缺陷：无法支持验证。 第三种选择是创建一个命令行工具，将拉取请求转化为一系列电子邮件。
他说，这其中有很多难题需要解决，也有很多折衷方案需要考虑。 但最简单的解决方案似乎是命令行工具，或许可以与GitGitGadget 这样的工具集成。sourcehut也正在开发一种工具，值得一看。 他可能会通过公开专门用于向 kernel.org 地址发送补丁的 SMTP 服务来支持这种工具。
这就引出了 "feeds "的概念--提供补丁和更多信息的服务。 lore.kernel.org服务已经运行了一段时间，并迅速成为内核开发过程中不可或缺的一部分。 不过，Ryabitsev 希望创建一个具有类似功能、但不需要邮件列表支持的服务。 开发人员可以用它来创建自己的补丁源；CI 系统也可以导出描述其运行的测试和结果的源。 这样就可以自动为补丁添加注释，例如说明这些补丁是如何被测试的以及测试者是谁。 机器人可以利用这些信息来确定它们应该运行哪些测试，避免那些已经在其他地方运行过的测试。 信息源将被存档和镜像，以便在多年后进行检查。 信息源将能够支持认证、记录Acked-by标签等。
但问题仍然是如何实际创建所有这些工具，并使其易于使用。 没有人会希望自己的收件箱中出现所有这些源，因此必须能够建立过滤器。 大小也很重要：lore.kernel.org 目前需要约 200GB 的磁盘空间，下载到笔记本电脑上有点不方便。 但 lore 包含大量开发人员通常不需要的古代历史，因此数据库可能会小得多。
Ryabitsev 目前正与public-inbox的维护者合作开发其中一些工具。 他说，在未来六个月内，LF还有一些开发时间；在这段时间内，他的目标是什么？ 对很多人来说，用 Docker 构建一些东西会很方便，但 "老派开发人员 "不想用 Docker。 它应该是命令行工具还是基于网络的工具？ 命令行工具的拥趸往往更有发言权，但这并不意味着他们占了大多数。
他说，也许开始的方法是让本地Patchwork实例的建立变得更容易。 关于如何支持分组维护的子系统，与会者进行了热烈讨论，但他说，这不是未来六个月就能解决的问题。 关于如何开发工具的进一步讨论被推迟到内核工作流邮件列表中进行。
随着时间的流逝，大家快速讨论了一些 CI 系统，包括 GitLab、Gerrit 等。 内核显然需要更多的 CI 测试，因此 Ryabitsev 希望确保所有这些都能集成到任何新工具中。 他希望能提供一个源，描述每个系统正在做什么。 现在，这些锻造系统大多提供了事件数据的应用程序接口；我们需要的是一套翻译机器人，它可以将这些事件整合到公共收件箱中，供任何感兴趣的人使用。 CI 系统可以使用这些数据，其他人也可以跟踪这些数据，而无需在每个 CI 系统上注册账户。
他说，现在 CI 系统发送的电子邮件对很多收件人来说都是噪音；随着越来越多的系统上线，这个问题会越来越严重。 创建一个馈送可以解决这个问题，把 CI 报告放在只有想要的人才能看到的地方。 电子邮件是与需要结构化数据的系统集成的一种糟糕方式，因此他希望用一种更结构化、基于馈送的系统来取代电子邮件信息总线。
会议结束时，有人表示，如果社区要求提供这种工具，那么 LF 很有可能会想办法为其开发提供资金。
[感谢 Linux 基金会、LWN 的差旅赞助商为编辑的差旅提供资助。
| 本文索引条目 | |
|---|---|
| 内核 | 开发工具 |
| 会议 | 欧洲开源峰会/2019 |
(登录发表评论)