LWN：libxml2 不再陪着玩安全漏洞披露游戏！

关注了就能看到更多这么棒的文章哦～

Libxml2's "no security embargoes" policy

By Joe Brockmeier
June 25, 2025
Gemini flash translation
https://lwn.net/Articles/1025971/

Libxml2作为一个 XML 解析器和工具包，几乎完美地诠释了开源运动的成功与失败。自首次发布以来的 25 年里，它已被开源项目、商业软件和政府广泛采用。它也说明，虽然许多组织热爱使用开源软件，但却很少有组织看到帮助其持续发展的价值。这导致 libxml2 的现任维护者拒绝了安全漏洞披露禁令（security embargoes），并引发了关于自由开源项目维护条款的讨论。

Libxml2 简史

最初的libxml，也被称为 gnome-xml，是由 Daniel Veillard 为 GNOME 项目编写的。他还开发了它的继任者libxml2，该版本于 2000 年初在 MIT 许可协议（MIT license）下发布，尽管 GNOME 应用程序通常采用 GPLv2 许可协议（GPLv2）。

21 世纪初，Veillard 似乎渴望其他项目在 GNOME 项目之外也采用 libxml2。它最初托管在自己的网站上，而不是 GNOME 的基础设施上。Libxml2 是用 C 语言编写的，但提供了针对 C++、Java、Pascal、Perl、PHP、Python、Ruby 等语言的语言绑定（language bindings）。其主页列出了 libxml2 实现的大量标准以及支持的各种操作系统，并自豪地宣称它“通过了 OASIS XML 测试套件（OASIS XML Tests Suite）中的所有 1800 多个测试”。“报告错误和获取帮助”页面提供了关于如何报告错误的详细指导，并指出 Veillard 将“及时”处理错误或缺失的功能。该页面由互联网档案馆（Internet Archive）在 2004 年收录，其中并未提及将安全报告与错误报告区别对待——但那是更简单的时代。

由此可见，为什么组织会放心地，甚至是被鼓励地，在他们的软件中采用 libxml2。当别人不仅已经造好了这个极其复杂的“轮子”，还吹嘘其适用性，并免费提供了一个宽松许可协议（permissive license）时，又何必再重新发明呢？

到了 21 世纪后期，该项目已趋于成熟，发布节奏也随之放缓。Veillard 继续维护该项目，但浏览GNOME xml邮件列表可以看出，他的注意力已主要转向其他地方。Nick Wellnhofer 于 2013 年左右开始对该项目进行定期贡献，到 2017 年，他已经承担了项目的大部分工作，最终主要负责发布——尽管 Veillard 仍是官方发布者。他还对一个相关项目libxslt做出了类似贡献，libxslt 是可扩展样式表语言转换（Extensible Stylesheet Language Transformations, XSLT）的处理器，用于将 XML 文档转换为其他 XML 文档、HTML 或纯文本等。

我需要我的 libxml2

2021 年 4 月，Stefan Behnel抱怨称，距离上一个 libxml2 版本发布已将近 18 个月。“在此期间，已经有很多修复，所以，请问是什么阻碍了新版本的发布？”Veillard回复说，原因是他工作太忙，并且“在发布前还需要完成一些事情”。这“一些事情”似乎是针对CVE-2021-3541的安全修复，这是一个 libxml2 中的缺陷，可能导致拒绝服务（denial of service）。libxml2 2.9.11（修复了该 CVE）和2.9.12的发布，似乎是 Veillard 对该项目的最后贡献。

随着 Veillard 逐渐淡出，Wellnhofer 成为了 libxml2 和 libxslt 的事实上的维护者（de facto maintainer），但他于 2021 年 7 月暂时辞职。他曾通过 Chrome 漏洞赏金（bug bounties）和其他 Google 项目为自己的工作提供资金，但表示：“安全研究的回报正在迅速减少，我看不出还有什么办法能获得最低限度的资金了。”

Veillard感谢了 Wellnhofer 的工作，并表示他不确定自己是否能够独自为这些项目提供相同水平的维护：“对于最近关注这些列表的任何人来说，这都是显而易见的。”

2022 年 1 月，Wellnhofer宣布，由于 Google 的一笔捐赠，他得以在 2022 年全年恢复对 libxml2 和 libxslt 的维护。他计划将项目迁移到 GNOME 的基础设施上，恢复发布，并建立一个官方途径来赞助 libxml2 的开发。最终，他选择了Open Source Collective作为财务托管方（fiscal host）。（LWN 在2024年报道了Open Source Collective。）截至目前，该项目似乎已经收到了高达 11,000 美元的捐款，其中大部分是 Google 的 10,000 美元捐赠，这笔资金似乎就是 Wellnhofer 在 2022 年期间用于 libxml2 维护的费用。

不负责任的行为

快进到 2025 年，Wellnhofer 于 5 月 8 日在 libxml2 的 GitLab 仓库中提出了一个议题，宣布了项目新的安全政策。他表示，他每周花费数小时处理安全问题，这对一个无偿志愿者来说是不可持续的。

作为 Wellnhofer 所面临困境的一个例子，以及可能压垮他的最后一根稻草，目前 libxml2 的议题跟踪器（issue tracker）中有四个标记为“安全”的错误。其中三个是安全研究员 Nikita Sveshnikov 于 5 月 7 日提交的，他受雇于一家名为 Positive Technologies 的公司。其中一个议题是关于空指针解引用（null-pointer deference）的报告，这可能导致拒绝服务。该报告中包含一个请求，要求 Wellnhofer 为该漏洞提供一个 CVE 编号，并提供预计的补丁日期。需要注意的是，libxml2 和 GNOME 都不是 CVE 编号授权机构（CVE Numbering Authorities, CNAs）。

关于 Sveshnikov 和其他研究人员报告的漏洞是否具有很大价值，人们可以争论。Wellnhofer认为他已经修复了大约 100 个类似错误，并且不认为这类错误是安全关键的。即使它是一个有效的安全缺陷，也很清楚为什么它可能会激怒维护者。该报告并非来自项目用户，也没有附带任何修复漏洞的补丁尝试。这只是对一位无偿维护者时间的又一要求，显然是为了让一家安全研究公司吹嘘这一发现以推广其服务。

如果 Wellnhofer 遵循维护者应有的“剧本”，他将花费数小时修复错误、与研究人员沟通，并发布新版本的 libxml2。Sveshnikov 和 Positive Technologies 将在他们的 CVE 记录上再添一笔，但 Wellnhofer 能从这种安排中得到什么呢？额外的开销、一个不想要的 CVE，以及对 libxml2 用户微不足道的实际好处。

因此，Wellnhofer 宁愿将安全问题视为普通错误，而不是遵守披露禁令并应对安全修复的截止日期；问题一经报告就会公开，并在维护者有时间时进行修复。Wellnhofer 还宣布他将辞去 libxslt 维护者一职，并表示该项目不太可能再被维护。他说，随着安全研究人员“紧盯着志愿者”，这种可能性更小了。

我越是思考，就越是意识到这是唯一的出路。我从事这项工作的时间足够长，知道围绕安全问题的大部分保密工作都只是作秀。所有像 OpenSSF 记分卡（OpenSSF Scorecards）这样的“最佳实践”，都只是大型科技公司试图让开源软件（OSS）维护者产生负罪感并让他们免费工作的尝试。

GNOME 贡献者 Michael Catanzaro担心，如果安全漏洞被当作普通错误处理，它们可能会在野外被利用，并为 Wellnhofer 在筋疲力尽时提出了替代策略。他同意，与 libxml2 安全问题相关的“富裕公司”应该通过成为维护者来提供帮助。否则，“后果就是安全问题肯定会在披露截止日期（无论设为多少）前公开，而在此之前它们还未被修复。”

Wellnhofer 对寻找“创可贴”式的解决方案不感兴趣；他表示，如果公司完全停止使用该项目，反而对项目的健康更有利：

关键是，libxml2 从一开始就没有达到在主流浏览器（mainstream browsers）或操作系统（operating systems）中使用的质量。这一切都始于苹果将 libxml2 作为其所有操作系统的核心组件。随后 Google 也效仿，现在甚至微软也在其操作系统（Edge 浏览器之外）中使用了 libxml2。这本不应该发生。最初这可能算是一种增长黑客手段（growth hack），但现在这些公司赚取了数十亿美元的利润，却拒绝偿还他们的技术债务（technical debt），无论是通过切换到更好的解决方案、开发自己的，还是尝试改进 libxml2。

这些公司的行为是不负责任的。即便他们声称并非如此，他们也并不关心用户的安全和隐私。他们只试图修补表面问题。

他补充说，他很乐意指导新的 libxml2 维护者，“但根本没有合适的候选人”。

Wellnhofer 表达的观点可以理解，尽管人们可能会对 libxml2 的质量不足以用于主流用途的说法提出异议。该项目网站上确实将其宣传为一款能胜任且可移植的 XML 解析工具包。开源倡导者在 1990 年代末和 2000 年代初花费了大量精力，试图吸引公司信任像 libxml2 这类项目的质量，因此现在很难指责这些公司当时认为它适合主流使用。

然而，Wellnhofer 指出这些公司在过去这些年里没有寻求改进或关心 libxml2，这一点完全正确。这似乎是“眼不见心不烦”的典型案例；只要没有已知的 CVE 困扰着这些应用程序所依赖的众多开源库，苹果、Google、微软或任何其他公司似乎都不怎么关心这些项目的维护。一旦发现漏洞，维护者似乎就被期望出于对整个生态系统的责任感而立即采取行动。

敢于说不

Wellnhofer 关于企业行为的论点在开源社区中引起了几位人士的共鸣。资深开源贡献者 Ariadne Conill观察到，使用开源的企业的回应是“公地监管捕获”（regulatory capture of the commons），而非贡献于它们所依赖的软件。

她提出，维护者缺乏能够轻易说“不”的“心理安全”（psychological safety）。他们 可以 拒绝公司的请求；然而，这样做意味着需要权衡“这样做的代价可能会对项目实现其最终目标的能力产生负面影响”。鉴于此，维护者可能会选择屈服于免费劳动的要求，而不是冒着未知的后果。

针对 Wellnhofer 对 libxml2 安全策略的改变，Mike Hoye提议项目应采用公开的维护条款，以表明“访问代码不意味着可以访问项目人员”。项目的条款将以一个MAINTENANCE-TERMS.md文件的形式包含在顶层目录中，类似于现在许多项目包含的 README.md 和 CONTRIBUTING.md 文件。Hoye 提供的示例维护条款声明软件是按原样提供（provided as-is）的，并否认任何承诺，包括响应时间、披露时间表，或任何“非合同义务或惯例，无论其假定的紧急性或严重性”。

Hoye表示，维护条款的目的是有意建立一种社会许可文化，让维护者能够安全地说“不”。否则，他说：

总有一天，会有人来找你，说：“我来自苹果，我来自亚马逊，我来自 Google Project Zero，你需要放下手头的一切，因为你的项目是新的心脏滴血漏洞（Heartbleed）或 Log4j 漏洞（Log4j），世界正在崩塌。”如果那时没有一个心理出口（psychological offramp），如果你没有提前清楚地说明“按原样提供”意味着什么以及你将如何处理，那么说一句“我要去参加孩子的独奏会”、“我正在度假”或者仅仅是“不”都将变得极其困难。

Chris Siebenmann表示，他认为 Wellnhofer 拒绝安全漏洞披露禁令是“未来此类事件增多的早期迹象，因为将有更多开源维护者反抗”。Siebenmann 说，目前的情况对涉及的维护者来说越来越糟，并且不可持续。他现在明确区分了企业对开源软件的使用与由志愿者运营的独立项目，如 Debian 或 BSDs；他预计未来其他人也会这样做。

维护者可能不想对其他志愿者说不。但是，Siebenmann 说，如果一家公司带着安全问题出现，他们可以指出维护条款——因为公司在使用开源时并不是作为合作企业的一部分，也不是“人”，“即便他们雇佣了那些会发出‘人是开源的’声音的人”。

Wellnhofer 的立场和 Hoye 的提议似乎与对企业开源行为有强烈看法的其他维护者产生了共鸣。开源维护者是否会普遍采用 MAINTENANCE-TERMS.md 文件作为一种常见做法，还有待观察。关于开源资金以及企业是否尽了自己份额的讨论日益频繁，这确实表明，如果开源要实现可持续发展，而不仅仅是维护者的一场傻瓜游戏（sucker's game），那么很快就需要做出一些改变。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～