世界を動かす技術を、日本語で。

無駄な報告書で時間を浪費するなら、あなたを禁止し、公然と嘲笑します。

概要

curlプロジェクトは、curl製品に関する セキュリティ問題の報告 を受け付け。 報告者への 金銭的報酬や補償は一切なし。 正当な報告には 感謝とドキュメント上での謝辞 を明記。 無意味な報告には 厳しい対応 を取る可能性あり。 連絡方法とポリシー詳細 も明示。

curlプロジェクトのセキュリティ報告方針

  • curlオープンソースプロジェクト は、curlプロジェクトが開発した製品に関する セキュリティ問題 の報告を受け付け
  • 金銭的な報酬や補償は一切提供しない 方針
  • 報告が 確認された問題 であれば、 感謝の意と謝辞 を公式ドキュメントで明記
  • 無意味な報告や時間を浪費する内容 の場合、公に BANや嘲笑の対象 となる可能性
  • 連絡先メールアドレス :security@curl.se
  • GitHubセキュリティアドバイザリーページ :https://github.com/curl/curl/security/advisories
  • 脆弱性開示ポリシー :https://curl.se/dev/vuln-disclosure.html
  • 謝辞リスト :https://curl.se/docs/security.html
  • 有効期限 :2026年10月22日まで
  • 公式セキュリティ情報ページ :https://curl.se/.well-known/security.txt

セキュリティ報告時の注意点

  • 英語 での報告を推奨
  • curlプロジェクト製品以外の問題 は受け付け対象外
  • 無意味な報告 (例:再現性のないバグや誤検知)は 厳しい対応 の対象
  • 感謝と謝辞 は、 確認された有効な問題 報告者にのみ提供

参考情報・リンク集

  • セキュリティポリシー詳細 :https://curl.se/dev/vuln-disclosure.html
  • 報告者謝辞ページ :https://curl.se/docs/security.html
  • 公式セキュリティ情報 :https://curl.se/.well-known/security.txt
  • GitHubアドバイザリーページ :https://github.com/curl/curl/security/advisories

Hackerたちの意見

https://curl.se/docs/bugbounty.html

報告とパッチ、そして説得力のあるテストケースにお金がもらえるなら、価値があるかもしれないね。たとえ機械がそれを生成しても。

AIの新時代。

みんなこれが来るのは見越してたよね。正直、こんなに時間がかかるとは思わなかった。

ポリシーのリンク[0]ページには、まだバグバウンティプログラム[1]へのリンクがあって、金銭的補償についても話し合われてるよ。

それについては言及されてないけど、今月末で終わるみたいだよね。 https://news.ycombinator.com/item?id=46701733 https://news.ycombinator.com/item?id=46678710

最近OWASPのドキュメントをちょっと手伝ってるんだけど、インドの学生たちが意味不明な問題やPRを次々と開いてて、コミュニケーションやコードが完全に100% LLMのものなんだ。お互いにやり取りすることもあるし、メンテナーにとっては大きな頭痛の種だよ。Ghosttyがやってるように、すべてをディスカッションから始めるのがいいんじゃないかって提案したんだ。メンテナーだけが問題を作成して、PRは問題からしか出せないようにする。これでこういう怠けた試みを抑止できると思う。

へへ、あの無料Tシャツコンテストを思い出すな… くじ引きでTシャツがもらえるチャンスのために、ランダムなFOSSプロジェクトにクソみたいなPRを提出するって、何が悪いことになるんだろう? https://ongchinhwee.me/shitoberfest-ruin-hacktoberfest/

まあ、もし人々が採用するなら、LLMの無駄話でディスカッションが溢れるかもしれないね。でも今のところは、これがより良い解決策みたいだ。

これ見たことあるけど、低音量でも疲れるよね。大体こんな感じで進むんだよね:誰かがゴミみたいな問題を作る。別の誰かがアサインしてくれって言う。プロジェクトの誰かが「うちは問題をアサインしないよ」って言うかもしれない(このステップは後のステップには全く影響しない)。別の誰かがPRを提出する。さらに別の誰かが別のPRを出すかも。メンテナは、失礼にならずに本気の努力を無駄にしないように、どうやって問題やPRを閉じるか悩むんだよね。

インドの学生たちが履歴書を誇張して、LinkedInやGitHubのプロフィールに注目を集めてる。見かけだけの知識を持ってる人が多いけど、それはただのLLMのエコーチェンバー。彼らが貢献するコードはLLMからそのまま出てきてる。これ自体は、彼らが何をしているか分かっていれば問題ないんだけど、変更を求めると、全然分からないって人もいる。トーバルズが言ってた通り、コードのメンテナンスはLLMのおかげで頭痛のタネになるね。

企業の文脈でも気づいたよ。今年見たパフォーマンスフィードバックの約40%がAIで書かれてた。インドとアメリカの人たち。ヨーロッパからのはかなりオーガニックに見えたけど、次のサイクルでは変わるかもね。

インドの学生たち これは文化的なものなのかな?数年前に小さなビジネスをやってた時(後に失敗したけど)、いろんな人に契約作業を依頼してたんだ。その時、インドの契約者は決して確認を求めないし、知らないことを言わないし、理解できないことを言わないってパターンに気づいた。彼らは自分の頭の中にあることをそのまま進めて、俺が指摘するまでそのままなんだよね。もし彼らが何かをうまくできなくても、俺が指摘しなければ「合ってたかな?もっと良くできたかな?」って思うだけ。なんでこんな態度なのか分からない。俺の仕事では時々「そのまま進める」けど、定期的にマネージャーに「これが欲しかったんだよね?」って確認する。これにはあまりデメリットがないよ。君のコメントは、彼らが「やってみる」って感じで似てるなって思い出させてくれた。

ここで生まれたことが本当に嫌だ。低品質なコンテンツ、DSAやLeetCodeとかの量が多すぎて、良い人やコンテンツが埋もれちゃう。ネットワーキングやコネ、ネポティズムがすごく多い。実際の才能で仕事を得るのは非常に稀。外では良いMNCも、ここではクソみたいなもんだし、まあ資本主義はどうでもいいって感じだよね。

ハクトーバーフェストは一年中だぜ、ベイビー! https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama

こういうスパムに対する防御は通常、社会的な恥なんだけど、今のインターネットには恥を知らない人がいっぱいだから、効果が薄いよね。今回はGeoIPを使った方が効果的だと思う。

俺は大きなオープンソースプロジェクトのソロメンテナと友達なんだけど、彼は毎学期の始まりに、偽のセキュリティ脆弱性報告やGitHubの問題が急増するって不満を言ってる。彼は、中国の大学が学生にソフトウェアの脆弱性を見つけて報告させることを課題の一部として奨励してると思ってる。彼らは、彼のGitHubリポジトリに実際に存在する脆弱性かどうかを確認してないみたい。彼はとても真面目で忍耐強いけど、問題が再現できないか確認するのに貴重な時間と注意を費やしてる。さらに、上流のブランチが主要なLinuxディストリビューションのフォークやプルから逸れてしまって苦労してる。時々、セキュリティ脆弱性は彼のアプリのLinuxディストリビューションパッケージのデフォルト設定であって、上流のデフォルト設定ではないこともある。そして、俺はKryptos K4のSubRedditにも参加してるけど、過去6ヶ月で「解決した!!!1!」って言ってる投稿の大半はLLMのコピペなんだ。LLMを使って全てを解決しようとするだけで、リサーチやアイデア出しはしてない。ひどくなって、SubRedditでは最初のLLMの投稿でユーザーをバンするようになった。教師たちが学生がAIを使って宿題を提出することを心配していたのが、仕事のあらゆる面に影響してるんじゃないかと心配してる。

「教師たちが学生がAIを使って宿題を提出することを心配していたことが、仕事のあらゆる側面に影響を及ぼしているのが心配だ。学問の世界でそうするように、市場でも同じことが起きている。今や金銭的なインセンティブがあるから、止まることはない。」

中国では医学生がオリジナルの論文を発表することが求められてる。でも、実際には誰かに書かせて文献を汚染してるんだよね。

人間として、知識を得たり成長する挑戦を楽しんでる。クリプトスタイルのAIハイプマンが「クロードはスライスしたパン以来の最高のものだ」と主張しても、そういうシステムの出力は脆弱で自信満々に間違ってる。嵐を乗り越えなきゃいけないかもしれない。ビッグテックが2025年にAI投資に1.5兆ドルも使うのに、世界を変えるような収益がないと無理だし、オープンAIが去年得た10億ドルの収益なんて何の意味もない。

ああ、TPBがMPAAやその「仲間」からメールを受け取った時のことを思い出す。これがまだ見れるページの中で一番いいページだと思う: https://web.archive.org/web/20111223101839/http://thepirateb... 結局役に立ったかは分からないけど、彼らは2003年から数年後の襲撃までずっとやってたみたいだし、メッセージを受け取ってなかったようで、結局試み続けてた。彼らの視点からすると理解できるけど、やっぱりね。

いろんなクソレポートのリンクはこちら: https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d... (出典: https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...)

たぶん、報告に対して「クレジット」や評判スコアみたいなものがあった方が効果的だと思う。GitHubならその情報を実装できるはずなんだけどね。

なんか、見出しを読み終える前にこれがcurlだって分かってた。彼らはよくやった!