cURL：如果你用垃圾等級的漏洞回報浪費我們時間，我們會封鎖你並公開嘲諷你 （★
105 分）
cURL 開源專案在網站的 .well-known/security.txt（security.txt：一種用來公開資安通報窗口的標準檔案）明確寫出：他們願意接收針對 cURL 相關產品的資安問題回報，但不提供任何獎金或補償；能給的是對「確認成立」的問題在文件中致謝與列名。檔案同時用非常強硬的措辭警告，若有人用「垃圾等級」的回報浪費維護者時間，將會被封鎖，並被公開嘲諷。
這份 security.txt 也列出通報管道與規範，包括電子郵件 security@curl.se、GitHub Security Advisories（GitHub 的安全通報／公告機制）頁面，以及漏洞揭露政策連結；並註明偏好語言為英文、致謝名單頁面、有效期限與「Canonical（正式版本位置）」連結。整體訊息等同於把資安通報的入口、期待與底線寫得非常直白：歡迎高品質、可驗證的漏洞，拒絕低成本、大量、無法重現的噪音。
Hacker News 討論普遍把這段強硬宣告視為「AI 垃圾回報」時代的反制：有人補充脈絡指出，cURL 近期正撤掉漏洞獎金計畫（bug bounty），希望降低因金錢誘因而湧入、由大型語言模型（LLM, Large Language Model）大量產出的低品質通報；也有人注意到政策頁面仍殘留舊的獎金方案連結，顯示轉換期資訊尚未完全整理。許多留言強調真正的成本在維護者的注意力與時間（opportunity cost），因為產出一堆看似像樣的文字很容易，但審查、重現、定位與修補的工作並不會等比例擴張；因此「沒有獎金」不代表沒有修補，反而是把貢獻留給真正在乎專案的人。
在如何抑制濫用上，社群提出多種做法並互相拉鋸：有人主張若能提供「附修補與測試案例」的高品質回報，付費仍可能值得；也有人提議採「可退還的提交費」來過濾垃圾，但反對者認為這會讓願意負責任揭露的人乾脆不回報。流程面則有人推薦改成先走 GitHub Discussions（討論區）或由維護者才可建立 Issue（議題），且 Pull Request（PR，程式碼合併請求）必須從既有 Issue 延伸，以降低「路過式」灌水；也有人厭惡用「AI 守門員」再去對付 AI，認為這只會把整個生態推向更荒謬的 AI 對 AI。
至於「公開嘲諷」本身，留言兩極：贊同者認為面對大量一次性干擾者，影子封鎖（shadow ban：對方不易察覺的封鎖）效果有限，公開羞辱反而能形成明確嚇阻；反對者則警告這會讓環境走向有毒，可能誤傷善意回報者，甚至讓被嘲諷者把它當成「徽章」去換取關注或資源。討論還延伸到類似 Hacktoberfest（每年 10 月鼓勵開源貢獻的活動）曾因 T 恤獎勵被「灌水 PR」玩壞的前例，以及對特定地區學生／承包商大量低品質提交的觀察與反駁；較審慎的看法指出不該簡化為國籍問題，而是不同教育與職場文化下的風險規避行為。整體共識仍是：在 AI 讓垃圾內容變得更便宜的情況下，維護者需要更硬的邊界、更好的流程設計，才能把有限精力留給真正可用的資安回報。
👥
43 則討論、評論 💬
https://news.ycombinator.com/item?id=46717556