LWN：关于明尼苏达大学事件近期情况的汇报！
关注了就能看到更多这么棒的文章哦～
An update on the UMN affair
By Jonathan Corbet
April 29, 2021
DeepL assisted translation
https://lwn.net/Articles/854645/
4 月 20 日，全世界都知道了明尼苏达大学（UMN，University of Minnesota）进行的一项研究计划，该计划设计有意提交错误补丁给 Linux 内核。在那之后，由这项工作产生的论文被撤回了，各种邮件来来回回，然后 UMN 的许多 patch 被重新 review。显然，现在是时候对最新情况进行一下介绍了。
关于这项研究的论文并不是最近事件的直接导火索。相反，这些事件是由 UMN 的另一位开发者提出的一个来源于实验性的静态分析工具的错误 patch 引起的。这导致内核社区的开发者们怀疑这些故意提交恶意 patch 的研究工作仍在进行。在那之后，已经证明其实并不是这么回事，但当整个来龙去脉变得清晰时，相关的争论已经在全速进行。
一句老话仍然适用：人们不应该把那些可以被解释为能力问题的东西归结到恶意之上（one should not attribute to malice that which can be adequately explained by incompetence）。
4 月 22 日，Linux 基金会技术顾问委员会（或称 TAB，technical advisory board，编者本人也是该委员会的成员）发表了一份简短的声明，指出不管其他什么争论，这次提出的 patch 似乎并没有恶意。同时，Linux 基金会和技术顾问委员会给 UMN 的研究人员发了一封信，概述了应该如何处理这种情况。这封邮件没有公开发布，但 ZDNet 显然从某个地方得到了一份副本。信中内容包括要求完全公开作为 UMN 项目的一部分而提交的错误 patch，并要求撤回这些工作所产生的论文。
作为回应，UMN 的研究人员发布了一封公开信，向社区道歉，几天后又发布了他们作为 "hypocrite commits（伪装提交）" 项目的一部分所做工作的总结。总共从两个傀儡帐号提出了五个 patch，但其中一个是普通的 bug fix，应该是不小心用了这个账号来发送。在剩下的四个 patch 中，有一个是试图插入一个 bug，但是这个实现本身就有问题，所以这个 patch 实际上是一个有益处的 fix；另外三个（1、2、3）包含隐藏的 bug。这三个都没有被 maintainer 所接受，尽管拒绝他们的原因并不完全是因为这些埋藏的 bug 本身。
论文本身已被撤回，不会按原计划在 5 月提交。大家基本上可以认为 UMN 近期不会再进行类似的研究了。
Patch re-review
UMN 的这些动作引起人们关注之后，一个直接结果就是，人们对 UMN 的开发者失去了信任，并且舆论希望采取一些惩罚性的举措。因此，当整个事件爆发时，最先发生的事情之一就是 Greg Kroah-Hartman 提出了一组190个patch组成的 patch series，他尽可能地移除了一些 UMN 的补丁。事实上，这并不是所有他发现的 UMN patch，因为他还提到了另外 68 个需要人工 review 的 patch 清单，因为它们不容易直接 revert。
实际上，这些 "容易 revert" 的 patch 也需要人工 review。一旦最初的愤怒过去，实际上就没有什么意愿去 revert 那些实际上没有错误的 patch 了。在过去的一周里，这种 review 工作一直在进行，有不少开发人员投入了精力。大多数可疑的 patch 被证明是可以接受的（尽管可能做得不是很漂亮），也已经从 revert 列表中移除出去了。如果编者的统计是正确的话，仍有 42 个 patch 将被从内核中撤出。
对于这 42 个 patch，需要 revert 的原因各不相同。有些 patch 是用在一些过时的、可能不再被使用的驱动程序之上，也没有人愿意去认真 review 它们了。其他一些 patch 中，没有很好地实现预期的改动，因此将会需要用更好的方式来重新实现。还有一些 patch 包含了严重的问题，这些肯定需要被 revert 掉（而且一开始就不应该被接受）。
不过，看过完整的这一系列 UMN patch 之后，我们更坚定了一些早期看法。首先，几乎所有的 patch 都解决了某种真正的（即使是晦涩难懂的）问题，也就是说这些 patch 是有理由的。虽然这些 patch 中有许多由于对代码的理解程度低因而带有了不少错误，但似乎没有一个是出于恶意的。
其实，"恶意（malice）" 有多种定义。对一些相关的开发者来说，把未经验证的实验性的静态分析工具生成的 patch 提交上来并且未告知大家这个情况，这就是一种恶意行为。这是另一种牵涉到未得到同意的人的实验。至少，这是对内核开发社区高效工作所依赖的信任的一种侵犯。
190 个 patch 中有 42 个有问题的 patch，也就是 22% 的有问题 patch 比率。其实对几乎任何一位内核开发者的 190 个 patch 进行详细 review 的话，都会发现一些回想起来并不是一个好主意的 patch。但愿这个比率不会有 22% 这么高。但必须要支持，所有这些补丁都被整个内核的多个子系统维护者所接受了，这不是一个很好的结果。也许这比最初研究人员所寻找的结果更有意思。他们故意插入 bug 的努力失败了，但却能在无意中增加几十个 bug。
同时，还有一份没有 revert 干净的 patch 清单。这个名单还没有公开发布，但 Kroah-Hartman 确实从其中的七个 patch 已经开始在做了。他还指出，TAB 将在所有这些 patch 的 review 完成后公布一份完整的报告。到目前为止，这些 patch 没有一个在 mainline 上被 revert，这可能会在 5.13 合并窗口结束时进行。
Lessons learned
从这一系列事件中得到的关键教训之一显然是：不要把自由软件开发社区作为你的实验性工具的一种免费验证服务。内核开发者很高兴看到新工具的出现，并且（如果这些工具能带来好的结果）使用它们。他们也会帮助测试这些工具，但他们不太乐意收到缺乏适当 review 和解释的、由工具产生的 patch。
另一个教训是我们已经知道的：内核维护者（以及许多其他自由软件项目的维护者）工作量过大，并没有时间正确 review 经过他们手中的所有 patch。因此，他们不得不依赖向他们提交 patch 的开发者的可信度。可以说，当这种信任能很好地维持住的话，内核开发过程就是勉强可持续的。而如果进入的 patch 一般来说不可以被信任的话，那么这个开发流程将无法维持下去。
这里的推论（也是我们早已知道的）就是进入内核的代码往往不像我们所想的那样得到很好的 review。如果人们相信每一行被合并的代码都经过了高质量的内核开发人员的仔细审查，那么确实会非常安心。事实上，有些代码确实得到了这种程度的 review，但不是所有的代码。例如以 5.12 开发周期（一个相对较小的周期）为例，它在十周的时间里向内核添加了超过 50 万行的代码。仔细审查 50 万行代码所耗费的精力将是无比巨大的，因此，非常不幸的，其中许多代码改动在被合并之前只得到了粗略的 review 而已。
最后一个教训是，人们可能会认为内核正面临着被比 UMN 的研究人员拥有更多技能和资源的人插入恶意patch的可怕风险。这可能是事实，但其实最简单的真相是这样的：正规的内核开发者继续在以这样的速度插入错误，而恶意行为者其实加入的不会更多了。2月份发布的 5.11 内核到 5.11.17 为止，在stable update中已经积累了 2281 个fix。如果我们做一个（可能过于简单了）假设，即每个fix都是修正了5.11 中的一个patch引入的问题，那么进入 5.11 的patch中有 16%（到目前为止）都是有错误的。这并不比 UMN patch所展现出的比率好多少。
所以，这也许是我们从整个经历中得到的真正教训：内核开发流程的速度是它最好的特性之一，我们都依赖它来尽可能快地获得功能。但是这种速度可能与严肃的patch review以及尽可能少的bug的要求是相冲突的。今后一段时间内，我们可能会看到流程变得慢下来，因为维护者觉得有必要更仔细地review那些改动，特别是来自新的开发人员的patch。但是，如果我们不能将更谨慎的流程给制度化固定下来的话，我们将会继续看到大量的 bug，而这些 bug 是否是故意插入的，其实并不重要。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～