# 安全地狱的下一层

# 安全噩梦的下一层地狱 Source: https://blogs.gentoo.org/mgorny/2026/10/27/the-next-circle-of-security-hell/ 几年前，我写了《现代打包者的安全噩梦》（https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/）。情况有没有好转？恰恰相反，我觉得我们正沿着一条涂满润滑油的斜坡一路下滑，而前方看不到尽头。漏洞以前所未有的速度被报告出来。许多人在竭尽全力修补漏洞，但这并不意味着他们没有把事情搞得更糟。复杂的软件牵涉复杂的依赖树，而这棵树上的每一个分支都需要照料。当某些分支不再可靠时，依赖链下游的人就开始承担更多压力。而一个人能做的事情是有上限的，所以最初为了解决上游问题而付出的努力，可能会迅速变成一种弱点。 如今的软件是不是更不安全了？说"是"似乎很诱人。我很想把责任归咎于企业界——它们自私自利地把低质量软件丢给我们；我很想把责任归咎于那些以利润为唯一目标开发产品的人；我很想把责任归咎于 Rust，它让人们沉迷于内存安全，却忽略了那些编译器抓不到的漏洞类型；最后，我真的很想把责任归咎于垃圾内容。但事实是，我不知道。而这其实并不重要。 重点在于，如今每个人以及他们的聊天机器人都成了安全研究员。项目正被漏洞报告淹没。尽管几乎所有的漏洞赏金计划都因为垃圾内容而被终止，但人们并没有停下来。即使我们把真正无效的垃圾报告排除在外，剩下的仍然很多，你总得想办法处理。你必须弄清楚这些报告有多重要，如何修复它们（或者更常见的是，判断提交的修复是否真的有效、不会引入回归问题），或者是否应该拒绝它们以及拒绝的理由。 归根结底，安全问题很棘手。我们看到大量像 REDoS 或其他类型的"性能 bug"。它们真的是漏洞吗？这取决于攻击向量。而这又取决于软件被如何使用。有些场景确实很离谱，感觉就像"如果你输入危险命令，shell 就能执行它们"。但同时，也存在真正严重的问题，比如"时序攻击可以用来猜测用户的密钥"。要做出这样的判断需要了解大量背景，而有时候你的判断与用户的期望并不一致。 那么，项目维护者最终能做什么？即使他们有专业知识和精力去做判断，即使他们"更了解情况"，CVE 很可能已经被分配了。它的评分可能高得离谱。除非你修复它，否则所有安全扫描工具都会报错，用户会来询问或抱怨，甚至攻击你或分叉项目。我是说，技术无法处理细微差别。我不止一次为了那些对 Gentoo 无影响的漏洞（例如，因为我们已经将易受攻击的依赖拆包处理了）进行不必要的安全稳定化更新，以避免安全扫描工具的误报。我还做过毫无意义的版本号提升（实际上没有任何改动，或者改动并不适用于 Gentoo），只是为了不让我们的软件包被报告为"过时"。这很麻烦、很糟糕，但至少能让人们不必担心。 我以前说过，现在再说一遍：大多数项目并没有为处理安全问题做好准备。这不仅仅是关于漏洞分类分级的问题。还在于是否维护 LTS 或安全分支，是否能够进行仅包含最小改动的正式安全发布。不幸的是，安全修复与新功能、弃用声明、API 变更合并在一起的情况非常普遍。在极端情况下，人们措手不及，突然需要在大型重写进行到一半时发布安全版本，或者与几乎未经测试的新代码一起发布。然后，下游的人发现他们需要快速应对重大 API 变更，才能升级到修复了漏洞的版本。这些问题不断堆积。 接下来会发生什么？社区会达到一个临界点。人们跟不上了。你发现自己无法依赖他人，于是你绕开他们。你开始打包更多东西。很快，你的工作量就超出了你的能力。软件开发变成了"每个聊天机器人各顾各"。噩梦变得更加糟糕，而车轮仍在不停地转。 ## 文章导航