Next steps for kernel workflow improvement

By Jonathan CorbetNovember 1, 2019

---

OSS EU

原文来自：https://lwn.net/Articles/803619/

Linux内核项目的开发流程一直是基于email的，这个方式建立已久，支持者众多，不过确实已经持续很多年头，可以考虑改进了。在2019 Kernel Maintainers Summit上，很明显可以看出来kernel的开发流程需要更新，maintainer（内核代码维护者）们也开始有些理解这个观点了。不过，能达成一致说要改善流程，距离真正实现这个流程以及说服开发者们，还有很大差距。在2019 Open Source Summit Europe上，有大约20位maintainer和开发者在吵吵闹闹的会议展览厅的一角进行商讨，希望能定下来应该先怎么开始。

这个会议由Konstantin Ryabitsev组织，他负责在Linux Foundation（LF，Linux基金会）管理kernel.org（此外还有其他一些职务）。他认为用email把patch发来发去来共同开发Linux kernel，并不是最优方案，尤其是在需要跟continuous-integration (CI，持续集成）流程结合起来的时候显得尤为麻烦。不过确实很多内核开发者对邮件方式还是很满意的。今后如果新加一些流程的话，很可能需要跟这个旧的流程共存，否则很难被接受。看起来近期在Linux基金会有些精力来推动内核开发流程的改进，尤其是看起来社区也很希望有这方面的改进。

Attestation

Ryabitsev的第一个目标，在Maintainers Summit上并不算多重要，不过这是他深思熟虑一段时间提出来的：改善针对patch的身份认证，这样收件人都能确保了解这些patch来自于谁。目前根本没有任何签名认证，因此开发者只能相信发件人的的名字。我们总是认为maintainer会仔细观察，能把那些试图混入kernel的邮件摘出来，不过事实上很容易让一段有风险的代码骗过maintainer。攻击者因此是有办法能在kernel里加入新的安全漏洞的。

因此，Ryabitsev认为，第一要务就是要确保身份认证可靠。Linus Torvalds确实会对pull request的签名tag都做校验，因此流程中最后这部分是可靠的。不过每个patch并没有附加签名，目前也没有通用方案来规定应该如何附加签名。

他希望能在email的patch里面也加上签名。可以利用minisign（而不是GnuPG）。使用minisign的最大优势是附加的签名信息会比GnuPG短很多。Steve Rostedt在这里打断了一下，他质疑这种方式是否真的有用。他说，攻击要想能成功（混入kernel代码），首先需要能仿照那个真实作者的样子来对kernel代码做一个相对来说非常复杂的改动。这个其实就很难了，如果黑客有这种水平，那就完全可以破坏安全签名的加密机制。

Ryabitsev认为，其实minisign已经非常安全，很难攻破了，并且比起攻破加密机制来说，有很多更容易的方法来把恶意代码塞入kernel。这种方式最难实现的部分其实是身份跟踪。GnuPG和此前的PGP一样，都是基于“web of trust"概念的，不过这么多年看下来web of trust其实多数时候并不可行，大家基本上已经在放弃了。新的方式更像是SSH这样，基于”trust on first use"（缩写TOFU）模式，如果这个秘钥第一次出现的时候被信任了，那么就会被持久信任并记忆下来。不过如果秘钥有改动的话需要经过仔细审查。他建议在Git里面也利用TOFU方式来做身份认证机制。

Rafael Wysocki也持怀疑观点，他认为这并没有解决问题，仅仅是把问题换到别的地方去了。攻击者可以伪造一个身份，随着时间的推移建立起信任关系，然后再提交一些恶意代码。因此他认为这个方案仅仅增加了复杂度，并没有解决任何问题。Ryabitsev却不同意，他认为建立信任会需要很多时间和资源，而攻击者可以很简单得伪造身份伪装成一个已经被大家信任的开发者，这一点现在就可以轻易做到。

Fank Rowand问，maintainer是不是需要在commit patch之前把签名删除掉？Ryabitsev说可以把签名放在changelog里的"---"这一行之下，这样就可以在commit的时候自动被删除掉。不过用来做验证的公钥会被存在本地的数据库里，等下次同一位开发者发出patch的时候会再次使用。Rostedt说，很多开发者只提一次patch，这样他们其实在数据库里就没有公钥存着。Ryabitsev说，这些开发者既然后面并不会再回来提交patch了，那么也就没什么关系了。这个方案主要是想解决那些长期开发者的信任问题。

他希望能把基于minisign的签名验证机制集成到Git里面，例如让git format-patch直接自动增加签名。Rowand指出，很多开发者都会使用旧版本的Git，因此这个功能会花很多年才会传播到所有开发者这里。他认为应该使用GnuPG，开发者都有GnuPG，并且kernel的web of trust工作方式已经是现成的。不过Ryabitsev认为GnuPG在对patch做签名这方面不是一个完善的工具，附加的签名信息经常比patch本身还长，而mailing list存档的时候通常都会把这个信息删除掉。如果要想真的用起来，就要确保patch里的签名信息不能太招摇。

这次会议上很多讨论内容达成的结论都是opt-in（可选进入），这个签名方式也不例外，至少暂时是这样。Ryabitsev打算写一个bot（邮件机器人）来监控mailing list，并礼貌地建议那些未加签名信息的开发者可以开始试着加签名了。他询问这些讨论者，这个方式是否可行，大多数人都表示赞同（Rowand例外）。因此他计划开始在Git里推动这方面的改动了。

Base-tree information

提交patch的人，经常被问到的一个问题就是：“这个patch是基于哪个代码tree来准备的？”。通常需要这个信息来确保能成功的apply一个patch。CI系统也通常需要这个信息来做自动测试。不过这个“base-tree information"在当前的patch里面并没有包含。很多开发者都希望工作流程能在这方面进行改善。Dmitry Vyukov问是否也把这个功能加到Git里等待合入，还是直接准备一个封装脚本来供开发者马上用起来。原来，现在Git的--base参数其实就可以用，只不过需要patch提交者都要利用这个参数。Yyukov也赞同确实很难让大家都用起来，因此建议最好建立一个封装脚本来自动设置好这个参数。

这里岔开讨论了一下，Torvalds是不是会抱怨这个base-tree信息，因为他之前在别人提出要加Change-id等tag的时候都不赞成。他并不是担心加了一个额外的tag，主要是不愿意加无用信息。既然大家赞同base-tree信息有用，那么他应该不会抱怨。

不过其他人马上指出，有些情况下可能base-tree信息并没有什么价值，比如这个base如果是在本地代码tree上的话。其他时候这个信息倒是确实是游泳的。Rostedt指出，x86维护中所用的"tip" tree其实有十多个branch，如果能知道这个patch该打到哪个branch上，那就会很方便了。所有人都赞同这个信息应该游泳，因此checkpatch.pl脚本后续会进行这个检查。可能也会加一个邮件机器人来提醒那些没有提供这个信息的开发者，不过还是要注意别导致太多噪音。

Beyond email

从很多角度来看，要求所有patch都经过email发送，这个策略应该不会长久持续下去。目前有个建议是利用起GitHub或者GitLab这样的服务，不过并没有得到广泛赞同，看起来短期内不可能采用。不过，很多开发者还是希望能新增一个不同于email的开发流程。在这个方向，第一步会是建立一种Git-to-email bridge。Ryabitsev指出，很可惜关于这个bridge应该长什么样，也并没有共识。

有一个方案，就是建立一个特殊的Git repository（仓库），开发者都有权限推送上去。每个被推送上去的patch都会自动变成email，发给合适的收件人。Ryabitsev觉得这个方法不好，因为这种类型的单一系统方案都会是一个瓶颈点，某个时刻它出错了，系统就全瘫痪了。还有个方案是建立某种网页服务，指向一个公开的git仓库，同样会转成email并提交。这个方案则有另一个问题，就是没法做好身份签名认证。第三个方案则是开发一个命令行程序，能把一个pull request变成一系列的email。

这里还有不少困难问题有待解决，很多地方需要权衡折中。不过最简单的方案看起来还是上面说的这种命令行程序，可能可以跟类似GitGitGadget这样的工具集成起来。在sourcehut上还有个在开发状态的工具也值得考虑。他会考虑作为对这些工具的支持，在kernel.org开放一个SMTP服务专用于发送patch给mailing list。

这又引出了一个“feeds”（信息流）的概念，对这些patch相关访问的服务。lore.kernel.org服务已经运行一段时间了，很快就成为了内核开发流程里的不可缺少的一部分了。Ryabitsev打算再建立一个类似的东西，不过并不需要依赖mailing list。开发者可以利用这个服务来创建他们自己patch的feed。CI系统也可以对外公布feeds信息来描述他们运行过的测试以及测试结果。这样就带来很多可能性，例如自动对patch进行标注，附加上它所经过的测试，以及测试者是谁。Bot（机器人）可以利用这个信息来确认它们应该执行哪些测试，避免执行那些别人已经跑过的测试。Feeds信息需要长期存档，并创建镜像站，这样几年后也能查到。Feeds还需要能支持身份签名认证，记录Acked-by tags等等功能。

不过，真正能创建出这些工具并让他们易用，还是需要很多功夫的。大家都不希望这些feeds信息塞满他们的收件箱，因此会需要建立过滤机制。并且存储空间也是一个问题：lore.kernel.org目前占用了200GB的磁盘空间，肯定不合适下载到个人laptop上。不过lore还包含了很多很久以前的信息，开发者通常并不需要，这样一来，用到的数据库就很小了。

Ryabitsev目前在和一个名为public-inbox的项目合作，希望能完成上述工具中的一部分。接下来6个月Linux基金会有一些开发资源，他应该着重完成哪些开发呢？可以考虑编译成Docker image，这样对很多人来说会很方便，不过对那些老派的开发者来说可能并不喜欢用Docker。或者是不是应该建立一个命令行或者网页工具？喜欢使用命令行工具的开发者声音更大一些，不过这并不代表他们真是大多数。

他说，也许可以先建立一个本地patchwork实例来作为开始。还有个讨论是有些kernel子系统是有一组maintainer来共同维护的，这种怎么支持，不过这个并不是接下来6个月需要解决的问题。大家同意后续在kernel workflows mailing list上来继续进行这些工具的开发工作的讨论。

时间不太够了，大家快速讨论了一下CI系统，包括GitLab, Gerrit等等。kernel确实需要更多的CI测试，Ryabitsev也希望能集成到新的工具里面。他打算提供一个feed，来描述每个CI系统在做些什么。这些系统大多都提供了一套针对event data的API，那么只需要一些bot来自动把这些事件都采集下来，集合送给感兴趣者的public-inbox feed即可。CI系统会使用这些feed数据来做一些工作，其他人直接follow这个feed即可，都不需要在每个CI系统上创建账号。

CI系统发出的邮件，目前对很多人来说都是一些噪音。随着更多的这类系统上线，情况也更加严重一些。只要创建成feed，就能解决这个问题，因为它可以把CI测试报告只放到人们希望查看的未知。这个工作做好不容易，他也不确定最终方案是怎样的，他会试试看。email很不适合来跟那些需要结构化数据的系统集成起来，因此他希望把email转变为一套更加结构化的、基于feed的系统。

这个话题结束了，他说，如果社区想要这类工具的话，那么很可能Linux基金会就会想法资助这个工具的开发。

Han-Wen Nienhuys也做了会议记录：https://docs.google.com/document/d/1khLOBw5-HyaaNX7xregpHQLSfvGDUeHDY921bkI-_os/edit

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting your editor's travel to the event.]