3 ポイント 投稿者 GN⁺ 2026-01-23 | 3件のコメント | WhatsAppで共有
  • curlオープンソースプロジェクト/.well-known/security.txt に記載された内容
  • 自社製品で発見されたセキュリティ問題の報告を受け付けるが、報告された問題に対して 金銭的報酬や報酬に類する特典は提供しない
  • その代わり、確認された問題については 文書内での謝辞とクレジット表記 を明記する
  • 質の低い、または無意味な報告 で時間を浪費させる場合、公開での嘲笑およびブロック措置 を警告している
  • セキュリティ報告ポリシーの要点を簡潔に要約した security.txt標準形式 を使用

curlプロジェクトのセキュリティ報告ポリシー

  • curlオープンソースプロジェクト は、curlプロジェクトが作成した製品のセキュリティ問題の報告を受け付けている
    • 報告はメール(security@curl.se)またはGitHubセキュリティアドバイザリーページから受け付け可能
  • 報奨金制度はない ことを明確に記しており、金銭的またはその他の形の報酬は提供しない
    • その代わり、確認された問題については関連文書で 謝意の表明と功績の明記 を行う

不適切な報告に対する警告

  • プロジェクトは 「役に立たない報告で時間を浪費させたら、禁止して公開で嘲笑する」 と明記している
    • これは、非専門的または根拠のない報告を防ぐための強い警告表現
    • 報告の品質と責任ある報告文化を重視している

セキュリティ報告手順と公式情報

3件のコメント

 
slowandsnow 2026-01-24

無分別なIssueの提起が続くなら、GitHubのIssueページを閉じるのが正解のようだ

 
skageektp 2026-01-23

公然とさらし者にするのは、韓国の法律では違法なんじゃないかという気もしますね(笑)

 
GN⁺ 2026-01-23
Hacker Newsの意見
  • 最近、cURL がAI生成の虚偽バグレポートであふれたため、バグバウンティ制度を廃止したという話を見た
    関連記事: Hacker Newsスレッド, ETN報道

    • レポートとパッチ、さらに テストケース まできちんと揃っているなら、たとえAI生成でも報奨に値すると思う
  • AI時代が本格的に始まったのを実感している

    • 誰もが予想していたことで、むしろここまで表面化が遅かったのが驚きだ
  • オープンソースの配布モデルは 持続不可能な構造 になったと思う
    もともと自由ソフトウェア運動は、ユーザーが自分で修正し改善する自由を保障するためのものだった
    ところが今では、イシュートラッカー、PRレビュー、メールサポート、セキュリティパッチまで無料で期待する文化が生まれている
    こうしたものは実質的に 有償サポート業務 であり、趣味でない限り報酬が必要だ

    • 昔、HapiJSで簡単な静的サイトジェネレーターを作ってGitHubに公開したが、Redditで広まるとPR、バグレポート、罵倒が殺到した
      「サポートするつもりはない」と明言していたのに非難が相次ぎ、それが自分にとって最初で最後の OSSプロジェクト になった
    • ユーザーが欲しい機能に 少額の報奨 をかけられる仕組みを想像している
      複数のユーザーが同じ機能を望めば報奨プールが大きくなり、開発者はその作業を選んで実行する
      プロジェクトマネージャーやテスターも一定の割合を受け取り、全員に動機づけが生まれる構造だ
    • オープンソースの創始者たちがこうしたモデルを意図していなかったという意見には同意しない
      Eric S. Raymond の「Bazaarモデル」と「Linusの法則(目が多ければバグは浅い)」は、まさに公開協業を前提としている
    • FOSS開発者を被害者として見る視点には反対だ
      自分で 境界とルール を設定し、無礼な人は遮断すればいい
    • GitHubのような公開イシュートラッカーを通じた協業は、すでに二世代にわたって オープンソースの基本文化 として定着している
  • 最近 OWASPのドキュメント化プロジェクト を手伝っているが、インドの学生たちがLLMで生成した的外れなPRやイシューを大量に上げてくる
    Ghosttyのように、まず「Discussion」から始めて、メンテナーが承認したイシューだけをPRに変換する構造が必要だと提案している

    • インドの開発者たちが、質問を避けてそのまま進める 「fake it till you make it」文化 を見たことがある
    • 多くの学生が 履歴書用のGitHub活動 のためにLLMコードでPRを送ってくるが、修正依頼をしてもまったく理解できていない
      Torvaldsが言ったように、LLMのおかげでコード保守は悪夢になりそうだ
    • こうした無意味なPRが増えると、本物のイシューを見つけにくくなる
    • Stack Overflowが衰退した理由の一つも、低品質な質問の急増 だと思う
  • 一度バグレポートを上げたとき、再現情報が足りないという理由でRedditで 激しい非難 を受けた
    その出来事以後、SNSでの活動はほとんどやめた

    • curlチームはたいてい丁寧に追加情報を求めるので、まともに応答しなければクローズされるのは当然だ
    • メンテナーは大量の誤ったレポートの中から本物のバグを探すのに苦労している
      批判はレポートに向けられたものであって、個人に向けられたものではないと覚えておくべきだ
    • curlチームはむしろ 寛大な方 で、Redditでの非難は公式コミュニティとは無関係だ
    • 皮肉なことに、今このスレッドの反応自体が「再現不能」な体験を扱っている
  • Eternal September とLLMが生んだ低品質な貢献の問題を解決するには、むしろ 参入障壁を高める摩擦(friction) が必要だと思う
    たとえば初回の貢献者は 絵はがきにQRコードでレポート を送らなければならない、というような形だ

    • ただしこうした摩擦は、むしろ本物の貢献者より スパム投稿者の方がうまく耐える 傾向があり、効果がないかもしれない
  • プロジェクトが絵文字とエラーだらけのPRの中でもがくようになると、もはや Bazaarモデル は機能しにくい

    • Brandolini’s Law を思い出す
      検証されていない情報があふれるのはオープンソースだけでなく社会全体の問題だ
      文化がまだ 偽情報に対する免疫システム を備えていない
  • 昔、The Pirate Bay がMPAAの法的脅迫メールを公開していた時代を思い出す
    TPBの法的対応ページ(ウェブアーカイブ) にその痕跡が残っている
    彼らのやり方が効果的だったわけではないが、一種の 抵抗の象徴 として残った

  • 友人が保守している有名なオープンソースプロジェクトに、中国の大学生たちが 虚偽のセキュリティ脆弱性レポート を課題用として提出してくる
    ほとんどが再現不能で、メンテナーの時間を浪費させる
    また、ディストリビューションごとの設定差のせいで、実際の脆弱性が アップストリームコードではなくパッケージ設定 に起因することもある
    Kryptos K4のサブレディットでもLLMが作った「解けた!」投稿があふれており、初回違反で即BANしている
    AIを使った宿題不正が今や あらゆる領域に広がった現実 が心配だ

    • 人間として 学びと成長の喜び を失ってはいけない
      AIがどれほど進化しても、自分で学ぶ価値 は代替できない
    • Kryptos K4では、LLMがすべてのデータを知っていても、新しいアイデアをまったく出せない
      結局LLMは創造的思考ではなく、強化されたオートコンプリートツールにすぎない
    • 中国では医学生が論文を自分で書かず、代筆で学術誌を汚染する ことがよくある
    • 結局、学界の不正は市場へとつながり、金銭的インセンティブ がある限りこうしたことは止まらないだろう
  • GitHubがユーザーに 信頼スコアや評判システム を与えるとよいと思う

    • だがGitHubは AI部門(Microsoft CoreAI) 傘下なので、こうした行動をむしろ奨励する可能性が高い
      関連記事: GeekWire報道
    • Microsoftが開発者に 社会的スコア を付けるのは恐ろしい発想だ
    • むしろユーザーを匿名化して 名声追求の動機 を減らす方がよいと思う
    • HackerOneのようなプラットフォームにも評判システムはあるが、低品質なレポート は依然としてあふれている
      結局企業は 一次審査(triage) サービスを有料で利用することになる
      この過程では実際の専門家ではない人が先に応答し、本物のレポート処理が遅れる問題も生じる
      今の状況は 誰にとっても悪い構造 であり、ますます悪化している