LWN：linux-distros 邮件列表的经验教训！
关注了就能看到更多这么棒的文章哦～
Lessons from the linux-distros mailing list
By Jake Edge
October 27, 2021
DeepL assisted translation
https://lwn.net/Articles/874069/
oss-security 邮件列表是专门设立出来用于报告和讨论开源软件的那些已经过了保密期的安全缺陷。但是，对最近一份关于 Linux 内核安全缺陷的 fix 报告的回复却走向了与往常不同的方向。该报告没有破坏两周的保密期的原则，但却 "迟到" 了，这凸显了这种类型的缺陷管理中的一些问题。
Lin Ma 的报告是关于内核中的近场通信（NFC，near-field communication）协议栈中的一个 use-after-free （free 之后继续使用）漏洞。它是通过 fuzzing 测试发现的，并在 9 月 1 日被正式报告给不公开的 security@kernel.org 和 linux-distros 邮件列表，当天就被分配了 CVE-2021-3760 编号。Ma 在 10 月 26 日（差不多两个月后）向 os-security 提交了一份关于该问题的详细报告。这个缺陷本身很难触发，它可能需要一个已经被攻陷了的 NFC 设备来发送恶意数据包序列才能触发。
管理 oss-security 和 linux-distros 的 Alexander Peslyak（或被称为 "Solar Designer"）回复时，强调指出了公开披露耗时过久，而 Ma 在报告中对此已经有表示了歉意。Peslyak 说，在处理发送给 linux-distros 的报告时就看到有多种问题存在。"让我们利用这个机会，从这个问题的错误的处理流程中吸取教训，避免在其他问题上出现这种情况"。
首先，Ma 给 linux-distros 的原始信息要求 14 天的封闭期（embargo），这是合理的，但并没有提及具体日期。由于这个时间段是合理的，因此看报告的人很容易接受下来，但 Peslyak 说，进行报告的 guideline 中确实要求要有一个日期。使用日期而不是天数会有一些好处：
当看到一个具体的日期/时间时，每个人都更容易注意到它的临近，而不仅仅是后续专门负责这个任务的人。这只是一个心理上的细节，我想在统计上来说还是会影响到结果的。
因此，我认为负责审查最开始的通知的发行版应该坚持要求指明实际日期和时间，或者要在后续处理时马上补上这个信息。
linux-distros 列表中有来自多个 Linux 发行版方的代表，这一点我们应该都可以想到。而那些影响范围不仅仅是 Linux 的问题，应该报告给另一个 distros 列表，因为那个列表中还有那些来自 FreeBSD、NetBSD 和 Solaris 的代表。正如在 linux-distros 的 policies and instructions for members 页面所描述的，每个发行版都被分别列出来负责处理 bug 报告中的某一类管理任务。还有一个发行版会被列为大多数 task 的后备军。这是发行版在被添加到列表中时所做出的 "contributing back" 承诺的一部分要求。而这次负责查看初始报告的两个发行版都没有指定准确的封闭期结束的日子。
此外，虽然 Ma 提出的 patch 确实合入了 mainline 内核，但 linux-distros 并没有被告知这方面的进展。Ma 在 upstream 上做的那些工作，都没有报告到此 list 里，发行商的代表也没有关注其进展。除此之外，相关的披露渠道（如 kernel mailing lists）上的监测也没有看到提及此漏洞，也没有人提醒 Ma 需要及时发布应该发表的 os-security post。也就是有多个不同的发行版在自己负责的这部分工作中都掉了链子。Peslyak 对这些活动的描述如下：
在这个问题上唯一的 "contributing back" 就只有在 linux-distros 上的 3 个回复：Red Hat 给出的 CVE ID 分配的提示，SUSE 在 9 月 17 日的 14 天后的提醒（也就是说，封闭期已经结束 3 天了），以及 SUSE（另一位工程师）在 10 月 25 日的另一个提醒（这个提醒最终见效了）。
最后一点，oss-security 报告中没有提到 upstream 里 fix 了这个问题的 commit，也没有提到它可以公开的日期。他要求 Ma 把这些信息都补上。此外，他还指出，这个错误影响相对较小，但它可以为今后的做法提供一些教训：
这个问题本身并不那么重要，这也是为什么它差点就被忽略的部分原因，但它对我们是个提醒，是我们在今后有更重要的问题被错误地处理之前就改正我们做法的好机会。
Ma 同意 Peslyak 的建议，但他之前并没有意识到需要让 linux-distros 了解 fix 的进展。Ma 指出了最终修复这个问题的 commit，并对 Peslyak 的帮助表示感谢。正如 Peslyak 所说，该 fix 方案已于 10 月 7 日发布到 netdev mailing list 中，事实上就打破了当时的封闭期，也就是说封闭期本应更早结束，所以这里没有造成任何坏的后果。他还说，在封闭期结束之后，大家都可以代替 Ma 来向 os-security 发出这个提醒，其实这个过程中有许多时间点都有这种机会。
至少到目前为止，只有一个被分配到 Peslyak 所强调的被丢弃的任务的发行版对此给出了回应。Amazon 的 Anthony Liguori 承认，该公司错过了作为 backup 角色需要持续关注 bug 和 fix 的进展，也表示希望继续在 "contributing back" 这方面继续努力。要想让 linux-distros mailing list 能够继续运作，那就显然需要参与人之间的合作努力。在这个例子中，这一点似乎已经不再可靠了，所以 Peslyak 正试图把问题扼杀在萌芽状态。
Peslyak 在他的第一次回复中提到，任务中还有一部分也没有进行处理，那就是对统计数据的收集。目前没有人被指派来做这项工作，他希望看到有一两个志愿者能站出来。他希望得到的数据就是来自 https://oss-security.openwall.org/wiki/mailing-lists/distros/stats ，并在 guideline 中也有详细的提及：
跟踪每个报告以及每个问题的处理和公开披露时间表（至少包括通知到不公开的 mailing list 以及实际公开披露的时间），定期制作和分享统计数据（最值得关注的就是平均封闭时长）以及原始数据（除了那些仍处于封闭期的问题），发布到 os-security。
收集这些信息就可以很好地监测 linux-distros 社区和工作流程的健康状况，但它也很可能可以直接帮助解决这次的问题：
[……]保持统计资料更新的话，还会带来一个很重要的好处，那就是会发现那些没有及时报告给 os-security 的 issue，或者根本没有报告过来的。例如，如果有人在 10 月 15 日更新 9 月份的统计数据（到那时 9 月份的内容正常来说应该全部都结束封闭期了），他们就可以提前 10 天发现这个问题。
mailing list 可以为其成员提供一些好处，可以在早期披露一些重要的 bug，协调大家的发布，使其他发行版不会被落下，等等。但这只有在这个过程可以良好运作的情况下才行得通，而这需要每个参与组织都在一定程度上承担自己的职责。
Linux-distros 是在它的前身（vendor-sec list）在 2011 年被破坏并解散后之出现的。vendor-sec 存在一些问题，比如封闭名单的规模（80-100 人）较大，因此 Linux-distros 的做法更加收紧了一些，并把对参与者的要求编写记录了下来。Peslyak 显然希望看到事情能重回正轨，所以我们也希望 linux-distros 社区能听从他这次的小提醒。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～