- curlオープンソースプロジェクト の
/.well-known/security.txt に記載された内容
- 自社製品で発見されたセキュリティ問題の報告を受け付けるが、報告された問題に対して 金銭的報酬や報酬に類する特典は提供しない
- その代わり、確認された問題については 文書内での謝辞とクレジット表記 を明記する
- 質の低い、または無意味な報告 で時間を浪費させる場合、公開での嘲笑およびブロック措置 を警告している
- セキュリティ報告ポリシーの要点を簡潔に要約した security.txt標準形式 を使用
curlプロジェクトのセキュリティ報告ポリシー
- curlオープンソースプロジェクト は、curlプロジェクトが作成した製品のセキュリティ問題の報告を受け付けている
- 報告はメール(security@curl.se)またはGitHubセキュリティアドバイザリーページから受け付け可能
- 報奨金制度はない ことを明確に記しており、金銭的またはその他の形の報酬は提供しない
- その代わり、確認された問題については関連文書で 謝意の表明と功績の明記 を行う
不適切な報告に対する警告
- プロジェクトは 「役に立たない報告で時間を浪費させたら、禁止して公開で嘲笑する」 と明記している
- これは、非専門的または根拠のない報告を防ぐための強い警告表現
- 報告の品質と責任ある報告文化を重視している
セキュリティ報告手順と公式情報
3件のコメント
無分別なIssueの提起が続くなら、GitHubのIssueページを閉じるのが正解のようだ
公然とさらし者にするのは、韓国の法律では違法なんじゃないかという気もしますね(笑)
Hacker Newsの意見
最近、cURL がAI生成の虚偽バグレポートであふれたため、バグバウンティ制度を廃止したという話を見た
関連記事: Hacker Newsスレッド, ETN報道
AI時代が本格的に始まったのを実感している
オープンソースの配布モデルは 持続不可能な構造 になったと思う
もともと自由ソフトウェア運動は、ユーザーが自分で修正し改善する自由を保障するためのものだった
ところが今では、イシュートラッカー、PRレビュー、メールサポート、セキュリティパッチまで無料で期待する文化が生まれている
こうしたものは実質的に 有償サポート業務 であり、趣味でない限り報酬が必要だ
「サポートするつもりはない」と明言していたのに非難が相次ぎ、それが自分にとって最初で最後の OSSプロジェクト になった
複数のユーザーが同じ機能を望めば報奨プールが大きくなり、開発者はその作業を選んで実行する
プロジェクトマネージャーやテスターも一定の割合を受け取り、全員に動機づけが生まれる構造だ
Eric S. Raymond の「Bazaarモデル」と「Linusの法則(目が多ければバグは浅い)」は、まさに公開協業を前提としている
自分で 境界とルール を設定し、無礼な人は遮断すればいい
最近 OWASPのドキュメント化プロジェクト を手伝っているが、インドの学生たちがLLMで生成した的外れなPRやイシューを大量に上げてくる
Ghosttyのように、まず「Discussion」から始めて、メンテナーが承認したイシューだけをPRに変換する構造が必要だと提案している
Torvaldsが言ったように、LLMのおかげでコード保守は悪夢になりそうだ
一度バグレポートを上げたとき、再現情報が足りないという理由でRedditで 激しい非難 を受けた
その出来事以後、SNSでの活動はほとんどやめた
批判はレポートに向けられたものであって、個人に向けられたものではないと覚えておくべきだ
Eternal September とLLMが生んだ低品質な貢献の問題を解決するには、むしろ 参入障壁を高める摩擦(friction) が必要だと思う
たとえば初回の貢献者は 絵はがきにQRコードでレポート を送らなければならない、というような形だ
プロジェクトが絵文字とエラーだらけのPRの中でもがくようになると、もはや Bazaarモデル は機能しにくい
検証されていない情報があふれるのはオープンソースだけでなく社会全体の問題だ
文化がまだ 偽情報に対する免疫システム を備えていない
昔、The Pirate Bay がMPAAの法的脅迫メールを公開していた時代を思い出す
TPBの法的対応ページ(ウェブアーカイブ) にその痕跡が残っている
彼らのやり方が効果的だったわけではないが、一種の 抵抗の象徴 として残った
友人が保守している有名なオープンソースプロジェクトに、中国の大学生たちが 虚偽のセキュリティ脆弱性レポート を課題用として提出してくる
ほとんどが再現不能で、メンテナーの時間を浪費させる
また、ディストリビューションごとの設定差のせいで、実際の脆弱性が アップストリームコードではなくパッケージ設定 に起因することもある
Kryptos K4のサブレディットでもLLMが作った「解けた!」投稿があふれており、初回違反で即BANしている
AIを使った宿題不正が今や あらゆる領域に広がった現実 が心配だ
AIがどれほど進化しても、自分で学ぶ価値 は代替できない
結局LLMは創造的思考ではなく、強化されたオートコンプリートツールにすぎない
GitHubがユーザーに 信頼スコアや評判システム を与えるとよいと思う
関連記事: GeekWire報道
結局企業は 一次審査(triage) サービスを有料で利用することになる
この過程では実際の専門家ではない人が先に応答し、本物のレポート処理が遅れる問題も生じる
今の状況は 誰にとっても悪い構造 であり、ますます悪化している