「有料顧客が X を必要としているのですが、いつ直してくれるのですか？」
(twitter.com/maximilianhils)- 規制業界（銀行・連邦機関など）の顧客を持つある企業ユーザーが、オープンソースツール mitmproxy の次回リリース日程を公開イシューで求め、既知の High・Critical 脆弱性のため自社顧客がそのソフトウェアを使えないと圧力をかけた事例
- 当該 脆弱性は mitmproxy が使用していないライブラリ部分 に存在しており、実際のユーザーには影響がない状況
- メンテナーは依頼を拒否せず、適時のパッチリリースが必要なら 有償サポート契約(support contract) を結ぼうと返答し、プロフィールのメールアドレスを案内
- 企業ユーザーはこの返答を 「冗談か、あるいは巧妙に偽装された恐喝の試み」 と受け取ったとして抗議メールを送付
- リリース日程を尋ねること自体は正当だが、「貢献や資金でどう支援できるか」という 協力的な姿勢 が必要だという点が核心であり、元のコメント投稿者はその後、心からの謝罪を送った
事件の背景
- 添付された文脈説明によれば、mitmproxy と一緒に配布されるある ライブラリに脆弱性 が存在するが、mitmproxy が使わない部分にあるため 実際のユーザーには影響しない
- この件が外部で 話題になった(went viral) 後、追加の文脈が説明された状態
企業ユーザーの最初の要求（GitHub イシュー）
- 16時間前、あるユーザーが別のプロジェクトメンバー @Prinzhorn に言及し、次回リリースの目標日(target date) を質問
- 銀行・連邦機関など 規制業界(regulated industries) の顧客は、規定上、既知の High・Critical 深刻度の脆弱性があるソフトウェアの使用を禁じられていると説明
- 待機(waiting)に関する自社方針を立てたいが、そのために 何らかの目標日 が必要だと要求
メンテナー mhils の回答
- メンバー mhils が15時間前に回答し、会社のコンプライアンス要件を満たすための 適時のパッチリリース に関心があるなら、サポート契約を設定する用意があると提示
- 連絡先はプロフィールの メールアドレス にあると案内（「:-)」表記を含む）
抗議メール（"Concerning response"）
- その後、us.ibm.com ドメインのアドレスから github@hi.ls 宛てに「Concerning response」という件名のメールが送信された（Jul 14, 2023 の表記）
- 「Mr. Hils」で始まり、問題をエスカレートさせたり GitHub イシュートラッカーを不要な言葉で乱したりするのではなく、直接的な回答 を得るために目標日要求をより適切に説明しようとした意図だと述べる
- このフォローメールが不快に受け取られないことを願い、それは意図 ではない と明記
- 強調箇所では、メンテナーの返答を 公式プロジェクトの回答ではない冗談、あるいはさらに悪く言えば 巧妙に偽装された恐喝の試み(thinly veiled extortion attempt) だと仮定すると記述（その後、プロジェクトの公式文書を確認している途中で文が途切れる）
メンテナーの立場整理
- 返答は 冗談ではなかった ことを明確にする
- 「有料顧客が X を必要としている、いつ直すのか」というような接し方は、オープンソースプロジェクトに自己紹介する 最善の方法ではないかもしれない
- リリース日程を尋ねること自体は不快ではなく、正当な質問(valid) である点は認める
- ただし、その文脈は「私たちはこの件に関心がある、どうすれば実現を支援できるか」（貢献または資金）であるべきで、「あなたが私たちの顧客に問題を引き起こしている」であってはならないという点が核心
まとめ
- 元のコメント投稿者が 心からの謝罪(genuine apology) を送り、メンテナーはそれに心から感謝している
- 皆に 善意を前提にする(assume good intentions) こと、そして親切に接してほしいと呼びかける
1件のコメント
Hacker News の意見
この issue を読むとhttps://github.com/mitmproxy/mitmproxy/issues/6051、IBM の要望はツイートで見えるよりずっと合理的です。
問題は mitmproxy の依存関係に CVE があり、mitmproxy は 3 月に依存関係を更新したものの、その更新を含む安定版リリースをまだ出していないということです。IBM 側は「いつリリースタグを打つ予定なのか、顧客に伝えられるスケジュールはあるのか」と尋ねています。
特に「いつ直すのか」と聞いているわけではありません。直すものはすでになく、「この依存関係の更新が入った新リリースをいつ作る予定なのか」と尋ねているのに近いです。
こうした質問自体が不当だとは思いません。もちろん、このような修正が特定の期間内に配布されることを望むならサポート契約を求めるのも不当ではありませんが、「サポート契約はメールで問い合わせてください」という即答はやや行き過ぎに見えます。
Maximilian はお金を払っていない人にリリース予定を提供する義務はありませんし、IBM が本当にスケジュール表を必要としているなら費用を払うよう提案するのも、まったくおかしなことではありません。IBM がそこまで重要視しているなら、今日にでも mitmproxy の社内リリースを自分たちで作ることもできるはずです。
「サポート契約はメールで問い合わせてください」と言った理由は、1) すでにそのスレッドで、この件についてパッチリリースは出さないと明らかにしていたこと、2) 相手が自分たちの有料顧客への影響を強調していたことです。
なので、そこで付け加えられることはそれだけでした。もっと良い表現ができたことには同意しますが、私の返答が完全に行き過ぎだったとは感じていません。
CVE 自体もでたらめで、私たちはその依存関係の該当部分を使っていません。
要望者が無料労働で利益を得る一方で、なぜメンテナーがただで働かなければならないのでしょうか。
不当なのは FrugalGuy の当然視する態度です。オープンソースのメンテナーに無償で働けと求めたうえで恐喝だと非難するには、かなり特別な偽善者でなければなりません。パートタイムで自由なオープンソースプロジェクトをやっているボランティアに要求を強制することはできません。
OP です。はっきりさせておくと、リリースに関する質問自体はまったく問題なく、妥当です。
ただし文脈は「私たちはこれに関心があるのですが、実現のためにどう手伝えますか」であるべきです。貢献であれ費用であれです。「あなたのせいで私たちの顧客に問題が起きる」になってはいけません。
要望者が一言間違えたせいで悲惨な目に遭ってほしいのではなく、大企業が自由なオープンソースソフトウェアと健全な関係を築いてほしいのです。
そのような契約を提案したこと自体、実はかなり親切なことです。FrugalGuy は「プルリクエストを送ってください」という返答を受けることもあり得ましたし、それを気に入ったかどうかは分かりません。
しかし問題が、すでに作られた修正に対するリリースがないことなら、それを貢献やお金でどう直せるのかよく分かりません。
これは、自分が何を「直している」のかも分かっていない情報セキュリティの間抜けたちの典型に聞こえる。自動化システムが CVE があると知らせてきたら、何でも「パッチ」しなければならないと思う類の人たちだ。
CVE が何を主張しているのか、自分たちの具体的な使い方が脆弱なのかを検討しない。知らないし、関心もなく、プログラマーでもない。ただチェックボックスを消さなければならないことだけを知っている。
h2database でも似たようなことがあった。ある「セキュリティ研究者」が、やるなと言われていることをやると悪いことが起きると見つけ、それでも CVE を要求して取得した。中身を見ればたわごとだと分かるが、こういう人たちにとっては CVE が存在するという事実だけが重要なのだ。
h2database の開発者の発言: https://github.com/h2database/h2database/issues/3686#issueco...
「ボランティアが開発したオープンソースプロジェクトを使っている『大企業』に、なぜ少しでも同情しなければならないのか理解しがたい。会社の金で誰かを雇って対応するか、似た商用ライブラリに金を払えばいい」
具体的な状況で例外を認める権限があったとしても、その判断を正当化するにはさらに多くの書類を書かなければならない場合がある。その追加書類が速度を落とし、成果評価の指標に不利に働く。
「コマンドラインでパスワードを渡すと、システム上の他のプロセスが ps で見られる」
当たり前の話だ。それが「高深刻度」の CVE なら、自分もセキュリティ研究者と呼んでいい。同じことを許しつつ「こうするな」という警告を付けているアプリケーションを、少なくとも五つ六つは思い浮かべられる。
情報セキュリティチームがレポートに出た脆弱性を上げ、管理者は怖がる。
開発者は更新し続けなければならない。本番運用ではない依存関係までそうだ。例外申請はできるが、それはまったく別の厄介事だ。
そして管理者は、なぜ開発作業が遅くなったのか不思議に思う。
残りの回答を実際に誰が確認しているのかも疑わしい。
自分のプロジェクトの一つでも、突然「いつ直すのか」「私も影響を受けていて、これは重要だ」というコメントが急増したことがある。そうした突然の関心はかなり奇妙だった。
ところが同じ頃、ある会社の上司が社員たちに、実際よりはるかに多くの人が影響を受けているふりをして私に圧力をかけるよう指示していた、という謝罪メールを受け取った。
誰かが自分の職場では攻撃的または威圧的な口調が非常に効果的だと学んだものの、ここでの交渉上の立場はまったく違うという点を理解していないように見える。
「いつになるか分からないと計画を立てられない」と、「あなたの作業で私は金をもらっているのだから、これをやるべきだ。急いでほしい」との間には微妙な違いがある。
依頼者が背景情報を抜いて尋ねていれば、前者により近く、後者にはあまり近くない口調になっていただろう。
その理由が他の多くのユーザーにとっても重要に見えるなら、メンテナーが機能追加やバグ修正をより早く行うべきか判断する助けになることがある。回避策があるなら、それを見つける助けにもなる。
開発者をゆすっていると呼んだのは不当だったが、最初のメッセージ自体には問題はなかったと思う。
オープンソースを使いながらサポートまで要求する企業の権利意識はすさまじい。利用制限のあるライセンスがもっと広く使われるようになってほしいし、OSI がただ「それはオープンソースではない!!!」と言うだけで終わらないでほしい。
そういうライセンスなら、こうした状況を防げるかもしれない。
いずれにせよ、OSI と FSF がここで強硬な立場を取るのはよいことだ。あなたの優先順位が彼らと合わないなら、なぜ彼らがあなたを満足させるために変わらなければならないのか。
好きなライセンスを使えばいい。彼らが承認しなくてもだ。それがなぜ問題なのか分からない。そもそも彼らの価値観を共有していないのに、なぜその組織があなたのライセンス選択に承認印を押さなければならないのか。
企業スポンサーにとって、利用制限を支持しないことは欠陥ではなく機能だ。
オープンソースと自由ソフトウェアの定義の周辺には、ものすごい教条主義もある。この定義に従わなければ人が群がって攻撃されやすく、これらの定義はしばしば聖書のように扱われる。支持者たちは、2023年の現実に合わせて調整が必要かもしれないという可能性すら受け入れようとしない。
衝突を避けるために新しい用語を作っても、オープンソースと自由ソフトウェアの擁護者たちは自分たちの言葉にこだわり、物語を支配しようとする。その言葉は、彼らの内輪では否定的な含意を持つように設計されている。
どんな目的であれソフトウェアを実行するユーザーの自由は自由 0 であり、Stallman はなぜ利用制限が役に立たないのかを非常に説得力をもって説明している: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
保証否認条項と同じように、自由ソフトウェアは無条件で与えられる。望むように改変する自由まで贈られているのに、無料のサポートとメンテナンスまで要求するのは無礼だ。ライセンスを変えたところで、そういう無礼な人たちがいなくなるとは思えない。
それに、ライセンス以外の形で、企業よりもオープンソースに親和的な選択肢もあり得る。たとえば、誰かが重大な issue を提起するには再現コードを公開しなければならない、といった形だ。
80年代にも、サポートが普通は無料で提供されていた時代に、企業が海賊版ソフトウェアでそういうことをしていたという話をよく聞いた。そうした悪ふざけを減らした唯一のものは有償サポート契約だった。
現実的な対応はライセンス違反で訴えることだけだが、大企業はおろか中堅企業を相手にそれを行う手段を持つオープンソース開発者は多くない。
「FrugalGuy」の行動は未熟で幼稚だが、mitmproxy のメンテナーは、もっとよい形で、丁寧かつ断固として、誤解やドラマの余地がない返答をすることもできた。
「mitmproxy のライセンスに従い、このソフトウェアは保証なしで現状のまま提供されており、プロジェクトのメンテナーは現在、別の優先事項と成果物に縛られています」
「したがって、GitHub の issue トラッカー上の発言だけでは、issue の優先順位を正当化するには十分ではありません。issue の優先順位を上げる唯一の方法はサポート契約を締結することであり、[here] で提供されています。条件については喜んで追加で議論します」
エンジニア1年分の給与程度なら、ある規模の企業にとっては何でもない金額で、数週間以内に修正が行われそうだし、それが公平だと思う。
あるいは本当にお金を払いたくないなら、自社のエンジニアを1人、数か月割り当てて、有料顧客に必要な部分をパッチし、アップストリームに貢献すればよい。
訂正: エンジニア1年分の報酬というのは、私の限定的で不正確な推定にすぎない。正確にどれほどの価値があるのかを言える立場ではないが、コードベースに慣れていないエンジニアなら、おそらく数か月分の労力はかかるだろうと推定している。
ただしそうすると別のコンプライアンス問題が生じる可能性があり、おそらくそれでやっていないのだろう。もちろん、それはオープンソースプロジェクトの問題ではない。
https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...
「次のリリースの目標日はありますか？」と単に尋ねるのは問題ではない。要求しているわけではないからだ。
「待つ方向で社内の理屈を組み立てようとしているのですが、何らかの目標日が必要です」という表現の「必要」は、mitmproxy 開発者への要求ではなく、他の人たちが彼に要求しているものとして読める。
このコメントでは依頼をしつつ、その依頼の商業的・個人的な動機を説明している。恐喝のような言葉を持ち出してメールで戻ってくるまでは、問題はなかった。
元記事には文脈と雇用主が両方入っていた。投稿者があえて避けようとしたのは明らかなのに、実際の GitHub issue を広めるのもひどい行為だ。
FrugalGuyとは、言葉を失う。