2022-01-26

cURLlog4j問題質問がされる件

オープンソースcURLの作者、某大企業から「24時間以内にこの質問に答えるように」との無礼なメールを受け取る - Publickey について思ったことをつらつらと。

概要

log4shell と呼ばれる脆弱性が 2021 年 12 月にあった。これは Java というプログラミング言語プログラムする際に、動作ログを記録するのに非常によく使われるライブラリ log4j にとても危険脆弱性があった。なにがそんなに危険かっていうと

マインクラフトサーバが乗っ取られたとか被害も有名。詳細は Piyolog さんの Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog あたりを参照。

そんなわけで即座に影響範囲脆弱性のない新しいバージョンになっているか調べろ!って IT 関連企業はとてもバタバタしていた。

という背景の中、オープンソースソフトウェアである cURL の作者にとても失礼な log4j問題に関する質問メールが送られてきて、「サポート契約すれば即座に教えてあげますよ」ってかっこいい返しをして盛り上がっている。

cURL とは

cURL (https://github.com/curl/curl]) はオープンソース(以下 OSS)の通信ライブラリコマンドラインツールLinux などのサーバからファイルダウンロードしたりするのにとてもよくつかわれるライブラリ

C言語で書かれている。

ライセンスMIT を参考にした独自ライセンス https://curl.se/docs/copyright.htm]

つっこみどころ

OSS基本的に無保証提供される。そのことはライセンスに明記されている。

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

そんな OSS に対して、

あなたがこのメールを受け取ったのは、■■があなたが開発した製品採用しているためです。私たちはこのメールあなたが受け取ってから24時間以内に、お読みいただいた上でご返答いただくよう要求します」 

といった上から目線メール開発者に送るというのは、IT 企業として無知にもほどがあるといったところ。加えて log4shell 問題名前のとおり log4j脆弱性なので Java でかつ log4j を使ってなければ影響はないのに、C言語でかかれた cURL に問い合わせているので問題を全く理解していない。(Java の j が消えるので log4shell という命名はどうなんだというのは個人的にある。つーか Poodle とか Spectre とかファンシー名前つけてあそんでんじゃねーとも思う。)

しかも緊急性の高い脆弱性に今ごろ質問?って感じ。

なお cURL はどうやら開発者Daniel Stenberg 氏が wolfSSL というところを通じて商用サポート提供しているらしい。 https://curl.se/support.html]

ということで、「サポート契約を結んでいただければ、喜んですべて速やかにお答えしますよ」 というのはネタでもなんでもなく、普通対応

でもこの返しかっこいいしあこがれちゃう

そしてブログに書いてある2回目の返信で、David名前を間違えられたのに対して、Fotune 500 の巨人ということで "Hi Goliath," と返しているのも最高にクールですね。

なんでこんなメールが送られてくるのか

あくま経験想像だけど

こういうフローが事前に規定されていて CVE とか問題が検知されると発動する。このとき担当大丈夫です!って回答するときエビデンス証拠)を求められるのだけど、クソな情セキは自社の担当言葉を信用せず、開発会社からの言質をとれ!って命令するので、くそメールスパムされるという背景があったりする。(担当無知だったりイケイケだと、とにかく下請けやらせればいいというパターンももちろんある)

そして情セキも経営層に報告するのに必要で、経営が0リスク信者だと報告が大変なのはわかる。わかるがそれを説得するのが情セキの仕事やで。

加えて担当レベルになると大手は「そんなん下請けやらせればいいだろ」ってマインドのところが多く、上から目線かつ丸投げすることが多いように思う。

理由

もちろん担当者はピンキリからこうとは限らないけど比較的多い印象。

ま、これ今回 Daniel Stenberg 氏が公表たからばずってるだけで、日本でもしょっちゅう行われているし、Hacker News みると海外でも一般的ムーブのようです。 LogJ4 Security Inquiry – Response Required | Hacker News

ほんと IT 業界地獄だな!

小さいところは

とかであんまり上から目線でこない感じはするけど、これはあくま個人資質なのでやべー人はやべーです。オラオラ系の中小とかやっぱいます。でもこんな細かいことはあんまり聞いてこない。(個人の感想です

この手のメールになんでカチンとくるのかって言えば

ということで、皆ちゃん保守サポート契約して、契約範囲質問しような!

そして金払ってても相手人間なんで、お互い敬意をもって接しような!

その他諸々

Public Key でこの件にからめて記載されている奴について

OSS「faker.js」と「colors.js」の開発者自身ライブラリ意図的改ざん 「ただ働きはもうしない」

https://www.itmedia.co.jp/news/articles/2201/11/news160.html]

ちな、これ詳しくないんだけど、OSS 作者が 「もうただ働きで支援をするつもりはない。これを機に、私に6桁ドルの年間契約書を送るか、プロジェクトを分岐させて他の人にやってもらうかしてほしい」 というのもよくわからないんだよなぁ。

火事財産失ってむしゃくしゃしてやったのかなんなのか。人気 OSS になったのに全然金にならんぜ!ってのが辛いのはわかる。が、OSSライセンス的に支援義務としてやる必要はないので、そんな義務的になってる報告は無視してええんちゃうんと思ってしまう。今回みたいにサポートフィーよこせみたいなスキーム必要だったのかもしれない。

あと個人開発で、善意でこれ便利だろ?って公開しているものに対して、辛辣言葉の心ないバグ報告やら改善要望は心には刺さるので辛いのはある。それで辞めてしまう人も居る。

ブコメフリーライドって書いている人が居るけど、MIT ライセンスでだしてんだから OSS理念である自由ソフトウェアという意味で、再配布、改変、利用は自由でいいんだよ。イヤなら MIT 以外のライセンスでだせばよい。古くは MySQL の Dual ライセンス最近Redis とか Mongo みたいに。

ただ、金欲しいとか大体 Donation 募集したりするとかやってると思うんだけど、そういうのもあったのかなかったのかがよくわからにぃ。ポートフォリオになるので、採用にはつかえるんじゃないのかね?

じゃなきゃ GitHub に Public でコード公開しないと思うんだけどな。いまいちピンとこないのであんまり言及しない。

RedisMongoDB、Kafkaらが相次いで商用サービス制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発

https://www.publickey1.jp/blog/19/redismongodbkafkaaws.html]

で、商用ライセンス問題。これ今回のくそムーブ問題じゃないのここに並べられるのに非常に違和感がある。なんか OSS大企業対立を煽るようなミスリードを誘っているように感じてしまう。

大手クラウドベンダOSSライセンスに則って利用・改変するのは問題がない。つーか儲かってるから金よこせっていうのはちょっと違うんじゃないかなと思う。

オリジナルを開発した会社リスペクトされず、商業的に儲からないってのは、心情的、道義的、人気的にどうなの?クラウドベンダも金払ってあげれば良いんじゃないの?とは思うよ。(2社は協業したけど)

ただ、オープンソースで公開するということは次のような利点を求めてするこって、それがイヤならプロプラで良いわけさね。

Apache License 2.0 とかのライセンスOSS として公表しているものの利用をフリーライド表現するのも、それがなんか嫌儲Evil ってのはちょっと判断できないかなぁ。

大手が自社でメンテできてしまう(できるようにする)というのは経営戦略であり、開発元がクローズにするってのも経営戦略。罵り合い合戦ちょっとなぁという感じ。

OSS理念的に改修した分は元のソースもっとフィードバックしろよってのはあるけど AGPL とかで出してないんだよなぁ。

この辺は賛否両論色々あるので気になったら調べてみて。

以上。ご査収ください。

  • これにトラバがつかないことが、増田住民の生体を物語っている

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん