Libxml2の「セキュリティ禁止措置なし」ポリシー

2025年6月26日原文(lwn.net)

概要

libxml2 は25年以上にわたり多くのソフトウェアで利用されてきたXMLパーサ
オープンソースの恩恵と課題を象徴する存在
現在のメンテナが無償労働の限界を訴え、セキュリティ対応方針を変更
大企業の貢献不足や、メンテナの燃え尽き問題が顕在化
プロジェクト維持条件の明文化など、今後のOSS運営手法が議論に

libxml2の歩みとオープンソースの現実

libxml2 はDaniel VeillardがGNOMEプロジェクト向けに開発したXMLパーサ
2000年初頭にMITライセンスで公開、C言語実装、多数言語バインディングを提供
OASIS XML Tests Suiteの全テストに合格、幅広いOS・用途で採用実績
初期はバグ報告・ヘルプ対応も積極的、セキュリティ対応は特別扱いせず
「車輪の再発明不要」と多くの組織が採用、オープンソースの成功例
- 2000年代後半に成熟、リリース頻度低下
- Veillardの関心低下後、2013年以降はNick Wellnhoferが主要貢献者に
- 関連プロジェクトlibxsltにも貢献

メンテナンス負担と資金調達の課題

2021年、リリース遅延への指摘とセキュリティ修正（CVE-2021-3541）対応
WellnhoferはGoogleのバグ報奨金等で活動資金を確保していたが、収入減少で一時離脱
2022年、Googleからの寄付（$10,000）で一時的に活動再開、Open Source Collectiveを財務ホストに選定
これまでの資金総額は約$11,000と極めて少額

セキュリティ対応方針の転換と背景

2025年、Wellnhoferがlibxml2の新セキュリティポリシーを発表
- セキュリティ課題の対応に毎週数時間を要し、無償ボランティアとしては持続困難
- セキュリティ研究者からの脆弱性報告・CVE要求が負担増大の一因
- パッチ提供や利用者としての関与なし、単なる「発見実績」目的の報告も
セキュリティ問題も通常バグと同様に即時公開・余裕のある時に修正方針へ
libxsltメンテナも辞任、「今後の維持はほぼ不可能」と明言

企業利用の責任とOSSメンテナの現実

大企業（Apple, Google, Microsoft等）がlibxml2をOSのコアコンポーネントとして採用
しかし、これら企業は保守・改善や資金提供に消極的
Wellnhoferは「企業は技術的負債を返済せず、OSSメンテナに無償労働を強いる」と批判
新規メンテナ志望者も現れず、プロジェクト継続の人材難

オープンソースコミュニティ内の議論

Ariadne Conillは「コモンズの規制的囲い込み」と企業の姿勢を批判
メンテナは企業の要望を断る心理的安全性を持ちにくい現状
Mike Hoyeは「MAINTENANCE-TERMS.md」など、明文化した維持条件の導入を提案
- 「コードへのアクセスは人的リソース提供の約束ではない」と明示
- メンテナが安心して「NO」と言える文化の必要性

今後のOSS運営とセキュリティ対応のあり方

セキュリティ対応の「ベストプラクティス」やOpenSSF Scorecards等がOSSメンテナに過度な負担
企業が本当に重要と考えるなら、資金や人材で積極的に貢献すべき
メンテナの燃え尽き・無償労働問題を解決するための新たな運営モデルやルール策定の必要性

Hackerたちの意見

すごく悲しい話だな。俺が関わってる数十億ドルのプロジェクトの大部分はlibxml2の上に成り立ってるけど、うちの会社は全然わかってない。マジで、XMLを毎日使ってる同僚たちも、lxmlを通じて間接的にしか触れてないから、libxml2のことなんて知らないんだよね。

└

マジで、XMLを毎日使ってる同僚たちも、lxmlを通じて間接的にしか触れてないから、libxml2のことなんて知らないんだよね。関連のXKCD: https://xkcd.com/2347/

└

まあ、彼らは生き残るために約15万ドルくらい出さなきゃいけないね、他の人の仕事にただ乗りするんじゃなくて。

アリアドネ・コニルさん、長年オープンソースに貢献している人が、オープンソースを使っている企業は「共通資源の規制捕獲」に反応していて、依存しているソフトウェアに貢献していないと指摘してる。今の時代、GPLがMITよりも優れているポイントの一つは、こういうタダ乗りの数十億ドル企業があなたのソフトウェアに依存して、時間を要求するのを明確に防いでいるってことを言うと、半分冗談じゃないよ。

└

使ってもらう気がないなら、オープンソースにする意味ってあるの？

└

それって、いくつかの会社がMITのソフトウェアのフォークを自分たちで維持して、バグ修正や機能追加をしてるけど、戻さないっていう前提に立ってるよね。正直、信じがたいな。

これらの「セキュリティバグ」の多くは、そもそも「セキュリティバグ」じゃないんだよね。サービス拒否攻撃が人の銀行口座を空にしたり、ヌードの自撮りがネットに広がったりするわけじゃない。例えば、[1]や[2]みたいな「特定のコンテンツでパニックが起きる」ってのが今や「セキュリティバグ」扱い。そういう基準なら、潜在的なパニックを修正するものは全部「セキュリティバグ」になっちゃう。俺はその基準で言ったら、キャリアの中で何百、いや何千もの「セキュリティバグ」を修正してきたと思う。ほとんど「セキュリティバグ」としては成立しないのに、「6.2 中程度」や「7.5 高」と評価されてる。さらに言えば、無数の「高危険度」の「正規表現によるDoS」とか、そんなのもあるし。最悪なのは、これが実際の高危険度の問題を見つけるのをめちゃくちゃ難しくしてること。これは無害なスパムじゃないからね。[1]: https://github.com/gomarkdown/markdown/security/advisories/G... [2]: https://rustsec.org/advisories/RUSTSEC-2024-0373.html

└

これらの「セキュリティバグ」の多くは、そもそも「セキュリティバグ」じゃないんだよね。サービス拒否攻撃が人の銀行口座を空にしたり、ヌードの自撮りがネットに広がったりするわけじゃない。それは全然違う。可用性も重要なんだ。誰も銀行口座を使えなかったら、銀行に意味なんてないよ。

└

すべては「セキュリティバグ」になり得る、正しい（間違った？）文脈ではね。

└

サービス拒否は…システムがどう動くかに依存する。DoSは、システムがどうなるかに影響を与えるかもしれない。例えば、AVが新しいファイルをスキャンできなくなったり、スキャンを早めるためにレート制限システムが壊れたり、共有システムのリソースを全部自分のために使ったりすることがある。これは孤立したセキュリティの問題ではめったにないけど、ライブラリは孤立して使われることはない。

└

完全な情報開示が「セキュリティ」バグを扱う唯一の公正で人道的な方法だよ。だって、あなたが指摘するように、どんなバグも誰かにとってはセキュリティバグだから。敵はどうせエンバゴリストに入ってくるしね。OpenBSD以外にも、原則を守って戦ってるメンテナーがいるのを見るのはいいことだね。

└

直接的に、または他のバグと組み合わせて使えるバグは、すべてセキュリティバグだよ。緊急電話に関連するシステムのサービス拒否は、人の命に関わることもあるからね。

Hacker Newsで議論の続きを見る

ハクソク