libexpat 的维护者 Sebastian Pipping 在博客里宣布了一件听起来像好消息的事：从 2026 年 8 月 1 日起,他将通过慕尼黑市的 Open Source Sabbatical 计划,拿到一份最长六个月的正式雇佣合同,专职修 libexpat 的漏洞。这个消息本身没什么可疑,他本人也在合同里、干活也是真的在干。但把这份"临时雇佣"当成开源基础设施困境的解法,还早。
libexpat 是 C 语言里最常被下游项目依赖的 XML 流式解析库之一,和 libxml2 并列,Firefox、Python 等一大批软件的解析逻辑背后都有它。可它二十多年来的维护方式,和 curl、OpenSSL 当年一样:靠一个人业余时间兼职撑着。慕尼黑这次出钱,恰恰是这套"关键基础设施押在极少数无偿志愿者身上"的老问题,第一次被一个地方政府正面接手。
六个月、六折工资、五个漏洞
先把这份合同的实际条款摆出来。慕尼黑 Open Source Sabbatical 的标准安排,是通过市属咨询公司 digital@M 签一份六个月定期合同,双方可随时解约,目标薪酬是申请者平时收入的六成。这不是给项目发补助,是把维护者"雇"成半薪的合同工。
Pipping 给自己列的首要任务很具体:修复5 个已知但尚未公开的漏洞,推进对 XML 1.0 第五版的支持,顺手提升项目的健壮性和可维护性。这份清单能不能在六个月内清空,决定了这次资助算不算真正见效。
官网没更新,不代表合同是假的
对照慕尼黑官方页面会发现一个时间差:截至目前,该计划公开列出的受助项目里只有一个——Integreat-Chat,2025 年上半年获批,页面上并没有 libexpat 的名字。申请方式也很朴素,靠邮件非正式提交给 opensource@muenchen.de,没有固定截止日期。
这不代表 Pipping 在编故事,更像是官方网站更新滞后于当事人的一手陈述,这种时间差在地方政府项目里并不罕见。但对读者来说,这提示一件更实在的事:这类资助目前还是一次一个项目、一个人、走内部邮件流程的手工操作,离制度化、可批量复制还有距离。
- 风险.资助规模停留在个案层面,libxml2、zlib 这类同样依赖单一维护者的关键库,暂时看不到被覆盖的迹象。
修的漏洞和长期目标,是两条不同的线
时间线上还有一个容易被忽略的细节。libexpat 从 6 月 15 日起进入"安全休假",暂停接收新漏洞报告直到 8 月 1 日,目的是先把存量问题清完。但恰恰在这个窗口期里,Mozilla 通过私密渠道报告了一个新漏洞,对应的修复 PR#1296 是 8 月 4 日刚提交的草案,目标合入 2.8.3 版本,CVE 编号目前还是占位符 CVE-TODO。
这个漏洞的性质,是 *_toUtf16 转换函数把 UTF-16 的低代理项误判成高代理项,导致越界读取和无限循环——纯粹的内存安全问题。它和 Pipping 长期任务清单里的"支持 XML 1.0 第五版"是两回事:后者是一份 2023 年就提出的字符集/命名规则升级草案,和这次的内存安全修复只在非 BMP 字符处理上有一点交集,不是同一条工作线。原文把两件事并列提及,容易让人以为它们互为因果,实际上各修各的。
六个月能清库存,清不掉"关键人物依赖"这个结构性毛病
六个月之后,谁来接手
对下游用户来说,眼下最实际的动作是关注 2.8.3 的发布节奏——尤其是把 libexpat 编译进 16 位字符模式的软件,这次 UTF-16 代理项漏洞直接影响到它们。对想提交漏洞的安全研究者,Pipping 自己说得很直接:这是"最佳窗口期",过了这六个月,响应速度大概率回落到志愿者节奏。
- 结论.这笔钱能解决存量漏洞,解决不了合同到期后谁来续命的问题。
真正值得盯住的,不是这六个月里能修多少个漏洞,而是合同结束那天,libexpat 是不是又变回了"靠一个人业余时间硬扛"的老样子。慕尼黑这次算是开了个头,但一次性、个案式的输血,离行业真正需要的可持续机制,还差得远。