先日libxml2のリポジトリに、楽しいテキストが追加されていました。
This is open-source software written by hobbyists, maintained by a single volunteer, badly tested, written in a memory-unsafe language and full of security bugs.
It is foolish to use this software to process untrusted data.
As such, we treat security issues like any other bug.
Each security report we receive will be made public immediately and won't be prioritized.
これは趣味人たちによって開発され、たった一人のボランティアによってメンテされているオープンソースソフトウェアです。
テストは適当で、メモリ安全ではなく、セキュリティバグも満載です。
信頼できないデータに対してこのソフトウェアを使用するのは愚かな行為です。
セキュリティバグは、他のバグと同様に扱われます。
すなわち、受け取ったセキュリティバグ報告は全てただちに公開され、優先的に修正されることもありません。
libxml2ってなに？
XMLを処理するライブラリです。
多くのLinuxディストリビューションやプログラミング言語に導入されており、さらにChromeやSafariといったWebブラウザでも使われています。
事実上業界標準と言えるかもしれません。
もちろんPHPにもあって、DOMやSimpleXMLなどがlibxml2に依存しています。
libxml2は2000年ごろにDaniel Veillardによって作成されました。
その後2013年ごろからNick Wellnhoferが貢献をはじめ、現在はNick Wellnhoferがほぼ一人で保守を行っています。
セキュリティバグ報告ってなに？
先日Felicaの脆弱性で少々話題になりましたが、セキュリティバグは基本的に通常のバグ報告と異なる扱いがなされます。
いきなりGitHubやその他メディアなどでセキュリティバグが公開されると、修正が間に合わないうちに攻撃者に利用されてしまうからです。
そのため、セキュリティバグについては各企業のバグバウンティプログラムやHackerOne、IPAなどの機関に報告し、修正されるまで待ってから公開する、という手順が確立されました。
もちろん報告を受けた側も、修正版がリリースされるまではセキュリティバグについては黙っておくというのが通例です。
これは協調的脆弱性開示プロセスと呼ばれ、現在では多くの開発者やアプリケーションが、このプロセスに従っています。
libxml2はこの業界標準をブッチし、セキュリティバグも一律全て公開する、攻撃者に利用されても知ったことではない、という斬新なセキュリティ対策に方針を切ったようです。
対応されてなかろうが90日で開示というポリシーを強行して大批判を食らったGoogle Project Zeroのはるかに上を行く対応です。
libxml2は長年使用されてきたため、どうしようもないほど致命的なセキュリティバグは流石に残っていないと思いますが、もし今後任意のディスクを読み取れるバグなんてものが見つかったりしようものなら、ほとんどあらゆるPC・サーバが危険に晒されることになるかもしれません。
どうしてこんなことに？
前々から幾度となく話題になっている、OSS開発者が全く稼げていない問題です。
Stepping down
2021/07/22の投稿。
I never really asked for it but in the last years I became de-facto maintainer of both libxml2 and libxslt.
Luckily, I was able to fund my involvement through Chrome VRP bug bounties and OSS-Fuzz integration rewards.
Big thanks to Google for these outstanding programs.
Unfortunately, returns from security research are diminishing quickly and I see no way to obtain a minimal level of funding anymore.
So I'm stepping down as contributor and maintainer.
特に頼んだわけでもないのですが、いつのまにかlibxml2とlibxsltの事実上のメンテナーになっていました。
幸いなことにChrome VRPバグバウンティとOSS-Fuzz Integration rewardsによって報酬を得ることができていました。
残念ながら、セキュリティからの収益が急減しており、最低限の資金を確保するめども立たなくなりました。
そのため、コントリビュータ・メンテナを退任することにしました。
Resuming maintenance
2022/01/10の投稿。
Thanks to a donation from Google, I'm able to resume maintenance of libxml2 (and libxslt) for the remainder of 2022.
Googleからの寄付のおかげで、2022年はlibxml2とlibxsltのメンテナンスを継続できるようになりました。
Triaging security issues reported by third parties
2025/05/08の投稿。
I have to spend several hours each week dealing with security issues reported by third parties.
Most of these issues aren't critical but it's still a lot of work.
In the long term, this is unsustainable for an unpaid volunteer like me.
毎週何時間も、第三者から報告されるセキュリティ問題への対応に追われています。
これらの問題のほとんどは致命的ではありませんが、それでも大きな作業です。
私のような無給のボランティアにとって、これは持続不可能です。
I'm thinking about some changes that allow me to continue working on libxml2.
The basic idea is to treat security issues like any other bug.
They will be made public immediately and fixed whenever maintainers have the time.
There will be no deadlines.
This policy will probably make some downstream users nervous, but maybe it encourages them to contribute a little more.
libxml2の開発を継続できるように、いくつかの変更を考えています。
基本的な考え方は、セキュリティバグを他のバグと同じように扱うということです。
セキュリティバグはただちに公開され、他のバグと同じ優先度で扱われます。
この方針は一部のダウンストリームを不安に陥れるかもしれませんが、もしかしたら貢献意欲を高めるきっかけになるかもしれません。
I've been doing this long enough to know that most of the secrecy around security issues is just theater.
All the "best practices" like OpenSSF Scorecards are just an attempt by big tech companies to guilt trip OSS maintainers and make them work for free.
My one-man company recently tried to become a OpenSSF member.
You have to become a Linux Foundation member first which costs at least $10,000/year.
These organizations are very exclusive clubs and anything but open.
It's about time to call them and their backers out.
長年この仕事をしてきたので、セキュリティ問題に関わる秘密主義のほとんどはただの茶番にすぎないものであるとわかっています。
OpenSSFのような"ベストプラクティス"は、大手テクノロジー企業がOSSメンテナーに罪悪感を抱かせ、無償で働かせようという圧力に過ぎません。
最近、私が個人経営している会社をOpenSSFのメンバーにしようとしました。
そのためにはまずLinux Foundationのメンバーになる必要があり、これは最低でも年間1万ドルかかります。
これらは非常に排他的な組織であり、なにひとつオープンではありません。
いまこそ彼らとその支援者を非難すべき時です。
In the long run, putting such demands on OSS maintainers without compensating them is detrimental.
I just stepped down as libxslt maintainer and it's unlikely that this project will ever be maintained again.
It's even more unlikely with Google Project Zero, the best white-hat security researchers money can buy, breathing down the necks of volunteers.
長期的には、OSSメンテナーに報酬も払わずにこのような要求を課すことは有害です。
私は最近libxsltのメンテナーを辞任しましたが、このライブラリがふたたびメンテナンスされる可能性はほとんどないでしょう。
Google Project Zeroという、金で買える最高のセキュリティ研究者がボランティアの首根っこをひっつかんでいる現状では、その可能性はさらに低いでしょう。
Triaging security issues reported by third parties
2025/05/10の投稿。
The point is that libxml2 never had the quality to be used in mainstream browsers or operating systems to begin with.
It all started when Apple made libxml2 a core component of all their OSes.
Then Google followed suit and now even Microsoft is using libxml2 in their OS outside of Edge.
肝心な点は、そもそもlibxml2はブラウザやOSクラスが使用できるレベルの品質を備えていなかったということです。
Appleがlibxml2をOSのコアコンポーネントに導入したことが始まりでした。
その後Googleも追随し、今ではMicrosoftでさえlibxml2を使用しています。
This should have never happened.
Originally it was kind of a growth hack, but now these companies make billions of profits and refuse to pay back their technical debt, either by switching to better solutions, developing their own or by trying to improve libxml2.
The behavior of these companies is irresponsible.
Even if they claim otherwise, they don't care about the security and privacy of their users.
They only try to fix symptoms.
このようなことは決してあってはならないことでした。
いまでは彼らは数十億ドルの利益を上げていますが、より優れたソリューションへの切り替えや自主開発、libxml2の改善といったフィードバックはありません。
これらの企業の態度は無責任です。
彼らはユーザのセキュリティやプライバシーなど気にもかけておらず、対症療法を行っているにすぎません。
I'm not playing part in this game anymore.
It would be better for the health of this project if these companies stopped using it.
私はもうこのゲームには参加しません。
彼らがlibxml2の使用をやめれば、このプロジェクトの健全性は向上するでしょう。
Stepping down as libxml2 maintainer
2025/08/15の投稿。
I’m stepping down as maintainer of libxml2 which means that this project is more or less unmaintained for now.
libxml2のメンテナーを退任することにしました。
つまり、このプロジェクトは現在ほぼメンテナンスされていないということです。
ここ最近libxml2を触っているのはNick Wellnhoferほぼ一人であり、彼が辞めるということはすなわちプロジェクトの放棄と同義です。
libxsltについては最近Iván Chaveroが後任に名乗りを上げたのですが、contributionもまだまだといったところです。
libxml2については今後どうなるか未知数です。
OpenSSFってなに？
OpenSSFは、オープンソースソフトウェアの開発・保守を持続的に行うことを推進する組織です。
有名どころとしては協調的脆弱性開示プロセスの策定・推進などですかね。
協調的なビジョンを達成するためには最低でも年間1万ドルの課金を要求し、実際のOSS開発者に貢献が還元されることは特にありません。
まとめ
協調的脆弱性開示プロセスは、OSSメンテナーにタダ働きを行わせるための脅迫でしかない、というなかなか強烈な主張です。
実際問題として、たとえばGoogle Project Zeroは、オープンソースが相手でも脆弱性の指摘しか行わず、脆弱性を修正したりパッチを作成したりすることはありません。
高い給料もらってるんだからパッチも書けよといった批判も多々あがります。
If Google was interested in actually improving the situation against hackers, they'd send or fund patches.
In reality they want to collect CVE scout badges.
Googleが真剣にハッカー対策をしたいのであれば、パッチを送ったり資金援助したりするでしょう。
彼らは単にCVEバッジを集めたいだけです。
CVE slop
感想
実は『放棄された』は言い過ぎで、現在は『メンテナがいない』状態であり、誰かが後任に立候補すれば開発は継続されるでしょう。
しかしメンテナになったところで報酬も利益もなく、負わされるのは時間と責任だけという損しかない立場です。
そのような立場に好き好んで入り込むのは、よほど風変わりな人しかいないのではないでしょうか。
見てのとおり、libxml2はあらゆるOSやブラウザや言語にまで入り込んでいる重大なライブラリです。
そんな根幹の部分がこんなことになっている現状、今後のOSSはどこに向かっていくのでしょうね。
apple-oss-distributions/libxml2
ちなみにAppleは独自に改造したlibxml2を公開していたりします。
しかし見てのとおりforkされていない独自パッケージであり、Apple専用コードが追加されているため、他プラットフォームで動作するかは怪しいようです。
また独自の修正を元のlibxml2にバックポートしたりもしていないようです。