我们能从明尼苏达大学事件吸取什么教训？
4 月 20 日，全世界都知道了明尼苏达大学（UMN）进行的一项研究计划，该计划涉及提交有意的错误补丁以纳入 Linux 内核。从那时起，由这项工作产生的一篇论文被撤回了，各种信件来来回回，来自 UMN 的许多补丁被审计。显然，现在是时候对情况进行更新了。
LCTT 译注：明尼苏达大学“伪君子提交”这件事引发了开源和技术社区的很多争议，我们也一直关注此事，本文是 LWN 编辑对事件后继发展的总结和观点。
关于这项研究的论文的撰写并不是最近事件的直接原因；相反，它是由 UMN 的另一位开发者发布的一个源于实验性静态分析工具的错误补丁引起的。这导致内核社区的开发者怀疑，提交故意恶意补丁的工作仍在进行。情况显然不是这样的，但当整个故事变得清晰时，讨论已经全面进行了。
LCTT 译注：提交“实验性静态分析工具的错误补丁”的开发者也是 UMN “伪君子提交”研究团队的成员，只是按该团队的说法，“伪君子提交”研究已经结束，最近引发争议的补丁来自另外一个项目。
老话仍然适用：不应该把那些可以充分解释为无能的东西归结为恶意。
4 月 22 日，Linux 基金会技术顾问委员会（TAB，写作本文的 LWN 编辑是该委员会的成员）发表了一份简短的声明，指出，除其他事项外，最近的补丁似乎是真诚地提交的。同时，Linux 基金会和 TAB 给 UMN 的研究人员发了一封信，概述了应该如何处理这种情况；该信没有公开发布，但 ZDNet 显然从某个地方得到了一份副本。除其他事项外，信中要求完全公开作为 UMN 项目的一部分而发送的错误补丁，并要求撤回这项工作所产生的论文。
作为回应，UMN 的研究人员发布了一封公开信，向社区道歉，几天后又发布了他们作为“伪君子提交”项目的一部分所做工作的总结。总共有五个补丁是从两个 sock-puppet 账户提交的，但其中一个是普通的 bug 修复，被错误地从这个错误的账户发送。在剩下的四个补丁中，其中一个是试图插入一个 bug，但是它本身没插入成功，所以这个补丁实际上是有效的；另外三个（1、2、3）包含真正的 bug，这三个都没有被维护者接受，尽管拒绝的原因不一定是有关的 bug。
LCTT 译注：根据 UMN 团队发布的总结：
- 第一个补丁是以“伪君子提交”而发出的，但是后来实际检查发现实际解决了问题，于是 UMN 团队就没有阻止该补丁被合入。
- 第二个补丁没有合入，但是内核维护者说之前有个别人的类似实现的补丁合并过，后来发现有问题而被别人撤销了。
- 第三个补丁没有合入，内核维护者发现了一个问题而没有接受，但是其实该补丁还有另外一个问题并没有被发现。
- 第四个补丁没有合入，和上一个类似，内核维护者没有发现有意放入的缺陷，而是找到另外的编码问题，因此没有合入。
- 第五个补丁是有效的补丁，但不是这个项目的，使用了错误的邮箱发出的。
论文本身已被撤回，不会按原计划在 5 月提交。希望大家可以认为 UMN 在短期内不会再进行类似的研究了。
LCTT 译注：在原文下面有不少评论认为这个研究方向应该继续下去，只是方式方法需要改善。
补丁的重新审查
UMN 活动引起的关注的一个直接结果是，人们对其开发者失去了信任，加上某些方面希望采取某种惩罚性行动。因此，当整个事件爆发时，首先发生的事情之一是 Greg Kroah-Hartman（GKH）发布了一个由 190 个部分组成的补丁系列，以撤销他能找到的尽可能多的 UMN 的补丁。事实上，这并不是所有的补丁；他提到了另外 68 个需要人工审查的补丁清单，因为它们不容易撤销。
碰巧的是，这些“容易撤销”的补丁也需要人工审查；一旦最初的愤怒过去，就没有什么愿望去恢复那些实际上没有错误的补丁。在过去的一周里，这种审查过程一直在进行，一些开发人员在为之努力。大多数可疑的补丁被证明是可以接受的（即使不是很好），已经从撤销列表中删除了；如果本文作者的计数是正确的，仍有 42 个补丁将被从内核中撤出。
对于这 42 个补丁，撤销背后的原因各不相同。在某些情况下，这些补丁适用于旧的、可能是未使用的驱动程序，而且没有人愿意去适当地审查它们。在其他情况下，其希望实现的变更做得很差，将以更好的方式重新实现。而有些补丁包含了严重的错误；这些肯定需要被恢复（而且一开始就不应该被接受）。
不过，看一下全套的 UMN 补丁，印证了一些我们的早期印象。首先，几乎所有的补丁都解决了某种真正的（即使是晦涩难懂的且难以解决）问题；为之写一个补丁是有理由的。虽然这些补丁中有许多显示出对代码的理解程度很低，因此包含了错误，但似乎其中任何一个修复程序的意图都不大可能是恶意的。
也就是说，“恶意”有多种定义。对一些相关的开发者来说，发布未经验证的实验性静态分析工具的补丁而不披露其性质是一种恶意行为。这是另一种涉及未经同意的人类的实验形式。至少，这是对内核开发社区有效工作所需的信任的一种侵犯。
LCTT 译注：如果研究涉及到人类，为了避免人类受到伤害，需要取得人类同意，这就是研究需要得到 IRB 许可的原因。UMN 认为 “伪君子提交” 不是针对人类的研究，给予了 IRB 免除许可。在这个事件中，有人对 UMN IRB 的意见也很大，而且怀疑 IRB 是否有能力对计算机相关研究给出有效判断。
这 190 个补丁中有 42 个坏补丁，坏补丁比率是 22%。很有可能，对几乎任何一个内核开发者的 190 个补丁进行详细审查，都会发现一些回想起来并不是一个好主意的补丁。但愿这个比率不会接近 22%。但必须说的是，所有这些补丁都被整个内核的子系统维护者所接受，这不是一个好的结果。也许这比最初的“伪君子提交”的研究人员所寻找的结果更有意思。他们故意插入 bug 的努力失败了，但却在无意中增加几十个 bug。
同时，还有一份不能干净地撤销的补丁清单。这个名单还没有公布，但 GKH 是从其中的七个子集开始的。他还指出，TAB 将在所有这些补丁的审计工作完成后公布一份完整的报告。到目前为止，这些补丁中还没有任何一个在主线上被撤销；这似乎有可能在 5.13 合并窗口结束时发生。
吸取的教训
从这一系列事件中得到的关键教训之一显然是：不要把自由软件开发社区作为你的实验性工具的一种免费验证服务。内核开发者很高兴看到新工具的产生，并且 —— 如果这些工具能带来好的结果 —— 就使用它们。他们也会帮助测试这些工具，但他们不太乐意成为缺乏适当审查和解释的工具产生的补丁的接受者。
另一个教训是我们已经知道的：内核维护者（以及许多其他自由软件项目的维护者）工作压力过度，没有时间正确地审查经过他们手中的每一个补丁。因此，他们不得不依赖向他们提交补丁的开发者的可信度。可以说，当这种信任得到妥善建立时，内核开发过程是勉强可持续的；如果通常无法信任进入的补丁时，那么它将无法维持下去。
推论 —— 也是我们已经知道的 —— 是进入内核的代码往往不像我们所想的那样得到很好的审查。我们希望相信每一行被合并的代码都经过了高质量的内核开发人员的仔细审查。有些代码确实得到了这种审查，但不是所有的代码。例如，考虑一下 5.12 开发周期（一个相对较小的周期），它在十周的时间里向内核添加了超过 50 万行的代码。仔细审查 50 万行代码所需的资源将是巨大的，因此，不幸的是，其中许多行在被合并之前只得到了粗略的审查而已。
最后一个教训是，人们可能倾向于认为内核正面临着被具有比 UMN 研究人员所展示的更多技能和资源的行为者插入恶意补丁的可怕风险。这可能是事实，但事情的简单真相是，正规的内核开发者继续以这样的速度插入错误，恶意行为者应该没有什么必要增加更多。2 月份发布的 5.11 内核，到 5.11.17 为止，在稳定更新中已经积累了 2281 个修复。如果我们做一个（过于简单的）假设，即每个修复都会修正一个原始的 5.11 补丁，那么进入 5.11 的补丁中有 16%（到目前为止）被证明是有错误的。这并不比 UMN 补丁的比率好多少。
所以，这也许是我们从整个经历中得到的真正教训：内核处理流程的速度是它最好的属性之一，我们都依赖它来尽可能快地获得功能。但是这种速度可能与严肃的补丁审查和低数量的错误不相容。在一段时间内，我们可能会看到处理变得有点慢，因为维护者觉得有必要更仔细地审查变化，特别是那些来自新的开发人员。但是，如果我们不能将更谨慎的处理流程制度化，我们将继续看到大量的 bug，而这些 bug 是否是故意插入的，其实并不重要。
via: https://lwn.net/SubscriberLink/854645/334317047842b6c3/