■ 1. libxml2のセキュリティポリシー変更
- libxml2のリポジトリに新しいテキストが追加された
- 内容:
- 趣味人たちによって開発され、たった一人のボランティアによってメンテされているオープンソースソフトウェアである
- テストは適当で、メモリ安全ではなく、セキュリティバグも満載である
- 信頼できないデータに対してこのソフトウェアを使用するのは愚かな行為である
- セキュリティバグは他のバグと同様に扱われる
- 受け取ったセキュリティバグ報告は全てただちに公開され、優先的に修正されることもない
■ 2. libxml2の概要
- XMLを処理するライブラリである
- 多くのLinuxディストリビューションやプログラミング言語に導入されている
- ChromeやSafariといったWebブラウザでも使われている
- 事実上業界標準と言える
- PHPにもあり、DOMやSimpleXMLなどがlibxml2に依存している
- 2000年ごろにDaniel Veillardによって作成された
- 2013年ごろからNick Wellnhoferが貢献を始めた
- 現在はNick Wellnhoferがほぼ一人で保守を行っている
■ 3. 協調的脆弱性開示プロセスの背景
- セキュリティバグは基本的に通常のバグ報告と異なる扱いがなされる
- いきなりGitHubやその他メディアなどでセキュリティバグが公開されると、修正が間に合わないうちに攻撃者に利用されてしまうためである
- セキュリティバグについては各企業のバグバウンティプログラムやHackerOne、IPAなどの機関に報告し、修正されるまで待ってから公開する手順が確立された
- 報告を受けた側も修正版がリリースされるまではセキュリティバグについては黙っておくのが通例である
- これは協調的脆弱性開示プロセスと呼ばれ、現在では多くの開発者やアプリケーションがこのプロセスに従っている
- libxml2はこの業界標準を無視し、セキュリティバグも一律全て公開する、攻撃者に利用されても知ったことではない、という斬新なセキュリティ対策に方針を切った
- 対応されてなかろうが90日で開示というポリシーを強行して大批判を食らったGoogle Project Zeroのはるかに上を行く対応である
■ 4. メンテナーの経緯:Stepping down(2021年7月22日)
- 特に頼んだわけでもないが、いつのまにかlibxml2とlibxsltの事実上のメンテナーになっていた
- 幸いなことにChrome VRPバグバウンティとOSS-Fuzz Integration rewardsによって報酬を得ることができていた
- Googleのこれらの優れたプログラムに感謝する
- 残念ながらセキュリティからの収益が急減しており、最低限の資金を確保するめども立たなくなった
- そのためコントリビュータ・メンテナを退任することにした
■ 5. メンテナンスの再開(2022年1月10日)
- Googleからの寄付のおかげで2022年はlibxml2とlibxsltのメンテナンスを継続できるようになった
■ 6. セキュリティ問題への対応(2025年5月8日)
- 毎週何時間も第三者から報告されるセキュリティ問題への対応に追われている
- これらの問題のほとんどは致命的ではないが、それでも大きな作業である
- 無給のボランティアにとってこれは持続不可能である
- libxml2の開発を継続できるようにいくつかの変更を考えている
- 基本的な考え方はセキュリティバグを他のバグと同じように扱うということである
- セキュリティバグはただちに公開され、他のバグと同じ優先度で扱われる
- この方針は一部のダウンストリームを不安に陥れるかもしれないが、もしかしたら貢献意欲を高めるきっかけになるかもしれない
■ 7. OpenSSFとセキュリティ業界への批判
- 長年この仕事をしてきたので、セキュリティ問題に関わる秘密主義のほとんどはただの茶番にすぎないものであるとわかっている
- OpenSSFのような「ベストプラクティス」は、大手テクノロジー企業がOSSメンテナーに罪悪感を抱かせ、無償で働かせようという圧力に過ぎない
- 最近個人経営している会社をOpenSSFのメンバーにしようとした
- そのためにはまずLinux Foundationのメンバーになる必要があり、これは最低でも年間1万ドルかかる
- これらは非常に排他的な組織であり、なにひとつオープンではない
- いまこそ彼らとその支援者を非難すべき時である
- 長期的にはOSSメンテナーに報酬も払わずにこのような要求を課すことは有害である
- 最近libxsltのメンテナーを辞任したが、このライブラリがふたたびメンテナンスされる可能性はほとんどない
- Google Project Zeroという金で買える最高のセキュリティ研究者がボランティアの首根っこをひっつかんでいる現状では、その可能性はさらに低い
■ 8. 企業の責任への批判(2025年5月10日)
- 肝心な点はそもそもlibxml2はブラウザやOSクラスが使用できるレベルの品質を備えていなかったということである
- Appleがlibxml2をOSのコアコンポーネントに導入したことが始まりだった
- その後Googleも追随し、今ではMicrosoftでさえlibxml2を使用している
- このようなことは決してあってはならないことだった
- 元々は成長のハックのようなものだったが、いまでは彼らは数十億ドルの利益を上げている
- しかしより優れたソリューションへの切り替えや自主開発、libxml2の改善といったフィードバックはない
- これらの企業の態度は無責任である
- 彼らはユーザのセキュリティやプライバシーなど気にもかけておらず、対症療法を行っているにすぎない
- もうこのゲームには参加しない
- 彼らがlibxml2の使用をやめれば、このプロジェクトの健全性は向上する
■ 9. メンテナー退任(2025年8月15日)
- libxml2のメンテナーを退任することにした
- つまりこのプロジェクトは現在ほぼメンテナンスされていないということである
- ここ最近libxml2を触っているのはNick Wellnhoferほぼ一人であり、彼が辞めるということはすなわちプロジェクトの放棄と同義である
- libxsltについては最近Iván Chaveroが後任に名乗りを上げたが、contributionもまだまだといったところである
- libxml2については今後どうなるか未知数である
■ 10. OpenSSFの実態
- OpenSSFはオープンソースソフトウェアの開発・保守を持続的に行うことを推進する組織である
- 有名どころとしては協調的脆弱性開示プロセスの策定・推進などがある
- 協調的なビジョンを達成するためには最低でも年間1万ドルの課金を要求する
- 実際のOSS開発者に貢献が還元されることは特にない
■ 11. Google Project Zeroへの批判
- 協調的脆弱性開示プロセスはOSSメンテナーにタダ働きを行わせるための脅迫でしかないという主張である
- 実際問題としてGoogle Project Zeroはオープンソースが相手でも脆弱性の指摘しか行わず、脆弱性を修正したりパッチを作成したりすることはない
- 高い給料もらってるんだからパッチも書けよといった批判も多々上がる
- 批判の声:
- 「Googleが真剣にハッカー対策をしたいのであればパッチを送ったり資金援助したりするでしょう。彼らは単にCVEバッジを集めたいだけです」
■ 12. 現状と今後の展望
- 実は「放棄された」は言い過ぎで、現在は「メンテナがいない」状態であり、誰かが後任に立候補すれば開発は継続される
- しかしメンテナになったところで報酬も利益もなく、負わされるのは時間と責任だけという損しかない立場である
- そのような立場に好き好んで入り込むのはよほど風変わりな人しかいない
- libxml2はあらゆるOSやブラウザや言語にまで入り込んでいる重大なライブラリである
- そんな根幹の部分がこんなことになっている現状、今後のOSSはどこに向かっていくのか不透明である