最新消息 UMN事件新进展:190个中发现42个“坏补丁” 仍有大量补丁需审核

4 月 20 日,全世界都知道了明尼苏达大学(UMN)进行的一项研究计划,该计划就是故意提交包含错误的补丁纳入到 Linux 内核中,甚至还根据该计划提交了一份研究论文 。目前论文已经被撤回,UMN 也公开发文致歉,UMN 提交的很多补丁都已经被重新审核 。
最新消息 UMN事件新进展:190个中发现42个“坏补丁” 仍有大量补丁需审核
文章图片

DJRPhoto36 / Flickr
这篇研究论文并不是最近事件的直接原因,而是 UMN 的另一位开发者发布的一个源于实验性静态分析工具的错误补丁引起的 。这个错误补丁引起了内核社区开发者的怀疑,随后整个事情被迅速点燃 。
4 月 22 日,Linux 基金会技术顾问委员会(TAB)发布了一份简短的声明,指出除了 UMN 等个别事项,最近的补丁似乎是真诚地提交的 。同时,Linux 基金会和技术咨询委员会给 UMN 的研究人员发了一封信,概述了应该如何处理这种情况 。
该信没有公开发布,但 ZDNet 显然从某个地方得到了一份副本 。除其他事项外,信中要求完全公开作为UMN项目的一部分而发送的错误补丁,并要求撤回这项工作所产生的论文 。
4 月 24 日作为回应,UMN 的研究人员发布了一封公开信,向社区道歉 。几天之后,他们以 PDF 文件汇总了他们在“hypocrite commits”项目中的工作 。总共有 5 个补丁是从 2 个 sock-puppet 账户提交的,其中 1 个补丁是普通 BUG 修复,只是错误地从错误帐号发送的 。而剩下 4 个补丁中,其中 1 个试图插入 BUG,而另外 3 个本身就存在 BUG 。这三个都没有被维护者接受,尽管拒绝的原因不一定是有关的 BUG 。
补丁的重新审查
UMN 活动引起的关注的一个直接结果是,人们对其开发者失去了信任,加上某些方面希望采取某种惩罚性行动 。因此,当整个事件爆发时,首先发生的事情之一是 Greg Kroah-Hartman 发布了一个 190 补丁系列,以恢复他能找到的 UMN 的许多补丁 。事实上,这并不是所有的补丁;他提到了另外 68 个需要人工审查的补丁清单,因为它们不容易恢复 。
碰巧的是,这些“容易恢复”的补丁也需要人工审查;一旦最初的愤怒情绪过去,就没有什么动力和愿望去恢复那些实际上没有错误的补丁 。在过去的一周里,这种审查过程一直在进行,涉及到一些开发人员的努力 。大多数可疑的补丁被证明是可以接受的,即使不是很好,也已经从恢复列表中删除了;42 个补丁仍将被从内核中撤出 。
对于这 42 个补丁,还原背后的原因各不相同 。在某些情况下,这些补丁适用于旧的、可能是未使用的驱动程序,而且没有人愿意去适当地审查它们 。在其他情况下,预期的变化做得很差,将以更好的方式重新实现 。还有一些补丁包含了严重的错误;这些肯定需要被恢复(而且一开始就不应该被接受) 。
但你如果观察下 UMN 提交的补丁,你就会发现一些共同点 。首先几乎所有的补丁都解决了某种真正的(即使是晦涩难懂的)问题;写补丁是有理由的 。虽然这些补丁中有许多显示出对代码的理解程度很低,因此包含了错误,但似乎不太可能有任何一个是恶意的 。
这就是说,"恶意 "有多种定义 。对一些相关的开发者来说,发布未经验证的实验性静态分析工具的补丁而不披露其性质是一种恶意行为 。这是另一种形式的实验,涉及未经同意的人类 。至少,这是对内核开发社区有效工作所需的信任的一种侵犯 。
在 190 个补丁发现 42 个“坏补丁”,意味着坏补丁率为 22% 。同时,还有一份没有恢复干净的补丁清单 。这个名单还没有公开发布,但Kroah-Hartman确实从其中的七个子集开始 。他还指出,TAB将在所有这些补丁的审计完成后公布一份完整的报告 。
吸取的教训
从这一系列事件中得到的关键教训之一显然是:不要把自由软件开发社区作为你的实验性工具的一种免费验证服务 。内核开发者很高兴看到新工具的产生,并且--如果这些工具能带来好的结果--就使用它们 。他们也会帮助测试这些工具,但他们不太乐意成为缺乏适当审查和解释的工具启发的补丁的接受者 。
另一个教训是我们已经知道的:内核维护者(以及许多其他自由软件项目的维护者)工作过度,没有时间正确审查经过他们手中的每一个补丁 。因此,他们不得不依赖向他们提交补丁的开发者的可信度 。可以说,当这种信任被很好地安置时,内核开发过程是勉强可持续的;如果进入的补丁一般来说不能被信任,那么它将无法维持下去 。
推论是进入内核的代码往往不像我们所想的那样得到很好的审查 。让人欣慰的是,相信每一行被合并的代码都经过了高质量的内核开发人员的仔细审查 。有些代码确实得到了这种审查,但不是所有的代码 。例如,考虑一下 5.12 开发周期(一个相对较小的周期),它在十周的时间里向内核添加了超过  50 万行的代码 。仔细审查 50 万行代码所需的资源将是巨大的,因此,不幸的是,其中许多行在被合并之前只得到了粗略的审查而已 。

推荐阅读