ハクソク

世界を動かす技術を、日本語で。

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

334日前原文(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以外にも、原則を守って戦ってるメンテナーがいるのを見るのはいいことだね。

└

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

└

最近の「セキュリティ」発表は3種類あるみたいだね。1. 深刻なもの。「これは問題で、昨日修正する必要がある。」2. マーケティング。「もし地球に月が2つあって、うまく配置されて、すでにローカルルートがあったら、blah blahってことができることを発見しました。ちなみに、あなたの偏執的な傾向にポジティブなフィードバックループを生むこの製品を売ってます、買って買って！」3. 評判を追い求めるもの。上と同じだけど、製品は売らずに、月を配置する専門家として自分を確立したいだけ。ちなみに、2や3は「AI」を使うとずっと簡単だよ。

└

ヌルポインタをデリファレンスするのはエラーだよね。これは確実にバグだ。メンテナは、アロケータの失敗（mallocがヌルを返す）によるものだって言ってるけど、それでもバグには変わりない。mallocの失敗を気にしたくないなら、malloc()がヌルを返したときにクラッシュするようにすればいいのに、全くチェックしないのはダメだよ。メンテナは、失敗したらクラッシュするようなmallocのラッパーを書いて、すべての呼び出しをそのラッパーに置き換えればいいだけだと思う。簡単に修正できそうだし。ほとんどのソフトウェアはヒープメモリがないと動かないから、プログラムが続行する意味がないよね。もう一つの解決策は、すべてのエラーを呼び出し元に返すことだけど、これは難しいし、呼び出し元が結果を確認しない可能性が高いから、面倒くさがられちゃう。バグレポートからの引用 [1]: > xmlSchemaNewValueがNULLを返す場合（例えば、mallocの失敗による）、xmlSchemaDupValはこれをチェックしてNULLを返す。 [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/905

└

セキュリティバグの基本的な定義は、機密性、完全性、または可用性を侵害するものだよ。DoSはアプリケーションの可用性に影響を与えるから、実際のセキュリティバグなんだ。深刻度は「銀行口座を空にする」バグより低いかもしれないし、修正の優先度も低くなるかもしれないけど、それが現実のバグであることには変わりない。

└

残念ながら、これはタイムリーなニュースだね： https://news.sky.com/story/patient-death-linked-to-cyber-att... > サービス拒否は... 結局、死に至ることがある。 （これはランサムウェアによるDoSだよ）

これは衝撃的な内容だね。「セキュリティバグはバグだから、消えろ」っていう感情は完全に正当だと思うけど、libxml2とlibxsltがほぼソロ開発者の情熱プロジェクトだったっていうのが問題なんだ。これはおもちゃじゃない。コンピュータのインフラの一部なんだから。

└

まさにHeartbleedの時のOpenSSLみたいだね。残念ながら新しいことではないし、「未知のOSSパッションプロジェクト」が全体のスタックを支えているっていうミームがネット中にあるよ。

└

この図にあるネブラスカプロジェクトは、ただの一つのプロジェクトじゃなくて、私たちの基盤となるソフトウェアインフラ全体を指してるんだ。 https://xkcd.com/2347/

└

タイムラインを間違えてるよ：libxml2はずっとソロ開発者の情熱プロジェクトだったんだ。その後、いくつかの大企業がそのインフラを使うようになったんだ。これは彼らの責任だよ。

└

これらのプロジェクトはおもちゃみたいなもんだ。真の問題は、何十億ドルもある企業が安全を守るためにおもちゃを使っていること。もしかしたら、私たちの基盤インフラをLEGOブロックやシリコン粘土で作るべきじゃないのかも。

要するに、libxml2は最初からメインストリームのブラウザやOSで使える品質じゃなかったと思う。メインストリームのソフトウェアの品質を過大評価してるんじゃないかな。確かに、メインストリームのOSやブラウザの一部はすごくよく書かれてるけど、他の部分は…

└

それがFOSSサプライチェーンの重要な要素を乱用したり、ただ利用したりする問題なんだよね。メガコープはちゃんと自分の分を払わないと、悪いことが起こる。結局、制限のない腐敗した資本主義と同じだよ。

└

自分はChromeのコードベースしか経験がないけど、C++（個人的にはあまり好きじゃない）だけど、結構しっかりしてるよ。変な部分はほとんど外部のリンクライブラリだった。ただ、そんなに深くは見てないけどね。

ソロの無給メンテナがユーザーから「プレッシャー」を感じるのが全然理解できない。私の返事はいつもこうだよ：「これは私のリポジトリ、私のコードだから、気に入らないならフォークすればいいじゃん、メガシュラッグ」。彼らに何も借りはないよ。それが意味するのは、メンテナやユーザー同士がクソみたいに接する必要はないってこと。ただ、ユーザーとしては感謝すべきで、与えられたものに満足するべきだよ、貢献したいなら別だけどね。言い換えれば、彼らに対しては、彼らが支払った分だけのものを返す義務があるってこと！

└

こういうことには、請求書が正しい返事だと思う。

└

あなたの解決策はまさに正しいけど、問題を理解する手助けをさせて。多くのオープンソース開発者は、自分が作ったものに対して責任感を感じてるんだよ。感情的に投資してるからね。好かれたいとか、嫌われたくないって思うこともある。あなたはそういうことを気にしないでいられるけど、他の人は気にしてるけど境界を設定する方法を学んでないんだ。もし大多数の人がやってることを理解できていないなら、あなたが違う側なんだってことを忘れないで。質問は「なんで私は違うの？」であって、「なんでみんな私みたいじゃないの？」じゃない。「これが解決策だ」って言う方が、「なんであなたは私みたいに考えないのか理解できない」よりもずっと良い印象を与えるよ。

└

ソロの無給メンテナがユーザーから「プレッシャー」を感じるのが全然理解できない。資金が豊富で成長を目指しているオープンソースプロジェクトは、バグレポートを出してくれるかもしれないという可能性にワクワクしてるよ [1,2]。他のプロジェクトでは、トップクラスのセキュリティバグに対して25万ドルの報酬を出すこともある [3]。小売や飲食サービスなどの社会の他の分野では、顧客が問題を報告するときに非常に謝罪的で従順な態度を取ることが多い。「ああ、申し訳ありません、あなたのバーガーにピクルスが入っていたのですね。ピクルスなしでお願いしたのに、本当にごめんなさい。それはすごくイライラさせたでしょう！すぐにキッチンに直させますし、もちろん無料のデザートもお持ちします。」だから、一部の人はオープンソースのメンテナとして良い仕事をすることは、こうした態度を真似ることだと思ってしまうんだ。バグレポートに感謝し、クラッシュに遭遇した全員にすごく申し訳ないと思わなきゃいけないってね。言うまでもなく、これは一人でプロジェクトを運営するには持続可能な方法じゃないよ、マゾヒストじゃない限りはね。 [1] https://llvm.org/docs/Contributing.html#id5 [2] https://dev.java/contribute/test/ [3] https://bughunters.google.com/about/rules/chrome-friends/574...

└

残念ながら、そういうことは裏目に出るんだよね。研究者はあなたの返答を公開して、「重要な問題を修正しない」とか皮肉を交えて言う。次に仕事を探してるときにHRがあなたの名前をググったら、それが出てきて、「あ、後で連絡するね」って感じになる。前にカーネルデバッグツールで働いてたとき、特にうざいセキュリティ研究者が、誤ったデバッグパケットでカーネルパニックを引き起こす可能性のある符号付き/符号なし整数のチェックについてしつこく言ってきたことがあった。ランダムなアドレスにランダムなことを書くだけでも同じことができるのに、実際にはフルメモリアクセスでカーネルをデバッグしてるのにね。悲しいよ。

責任ある開示には2種類ある：調整された開示で、そこには禁止がある（表向きは、メンテナが脆弱性が広まる前にソフトウェアをパッチできるようにするため）と、完全開示で、禁止がない（ユーザーが自分で脆弱性を軽減できるようにするため、すでに悪用されている場合に便利）。メンテナが完全開示をデフォルトにすることを許可されない理由はないよ。一般的に、関与するすべての当事者は完全に開示することができる。無責任な開示は、脆弱性を悪用するグループにのみ開示すること、例えばNSOなどだ。

└

そうそう、まさにその通り。これらの決定によって大企業が痛い目に遭うのが裏のメッセージだよね。でも、大企業はこういうことをいつも回避してる。OpenSSLがいい例だね。

ここでの問題は、セキュリティ研究者（もしくは一人だけかもしれない）が、このプロジェクトを「評判」のために「ファーミング」していることみたい。まるでNPC相手のコンピューターゲームみたいに、時間をかけた分だけ報酬が得られると思ってるみたいだけど、実際にはリアルなボランティアのメンテナにかなりの負担をかけてるんだろうね。メンテナは、実際のユーザーからリアルな問題を報告されて、しかも同時にパッチを提供されれば、もっと気にしないと思うけど、これらのバグはスキャンツールや理論的な問題を探してる人の目によるものだろうね。上記を考慮すると、提案されたMAINTENANCE-TERMS.mdはすごく理にかなってると思うけど、CVEsを探しているセキュリティ研究者や責任ある開示を気にしている人は、ライブラリを配布しているソフトウェアのベンダーに連絡すべきとも書いておくべきだと思う。そうすれば、ライブラリを利用している大企業が、自分たちのリソースを使ってセキュリティ研究者の懸念に適切に対処する責任を負うことになるし、彼らは自分たちで修正作業の大部分を行い、メンテナと連携してタイムリーにリリースを出せると思う。もしメンテナが、セキュリティの問題で来る人たちが事前にできる限りの作業をしてきたら、きっと喜んで手伝ってくれると思うよ。

プロジェクトが立ち上がると、オープンソースの開発者たちはそれを宣伝したがるし、履歴書に載せたり、カンファレンスで話したりするよね。企業が何かをスポンサーする義務はないし、これがオープンソースの理由じゃない。確かにオープンソースは90年代初頭から変わったけど、ユーザーが増えて、企業が他の人の仕事を使って何百万も稼いでる。メンテナの気持ちも分かるよ、感謝の気持ちがない人たちに対して。与えずに要求するのは辛いよね。オープンソースのライセンスは不十分だと思う。オープンソースプロジェクトは、セキュリティの修正、外部からの貢献を受け入れるかどうか、プロジェクトが機能的に完了しているかどうかについて、はっきりとした意見を示すべきだと思う。標準的なライセンスのように、標準化された、解析可能なメンテナンスの「契約」を持つべきだ。「お金を払った分だけ修正する、何も修正しない、自分の判断で修正する。開示なども含めて。」みんなが何を期待できるかを明確にするためにね。

自分がいくつかのオープンソースプロジェクトを維持してきた中で、こういうセキュリティ研究者とかCVEsってやつが本当に嫌いだった。ユーザーからの報告で影響の大きいバグを修正することが多かったけど、こういう会社が大きなバグを見つけると、まるで大騒ぎするみたいにして、実際の影響はかなり小さいのにね。UIのタイプミスを除けば、ほとんどのバグはセキュリティバグ扱いされるし、すぐに疲れてくるよ。CVEsが出ると、たくさんの宣伝や要求がついてくるしね。