curl 將在 2026 年 7 月暫停接受漏洞通報 （★
142 分）
curl 專案宣布，2026 年 7 月整個月將暫停接受與處理漏洞通報，稱為「curl summer of bliss」。自 7 月 1 日歐洲中部夏令時間 00:00 起，HackerOne（常用於漏洞通報與漏洞獎勵的平台）上的 curl 提交流程會暫停，直到 8 月 3 日 09:00 才恢復；安全通報信箱也不會處理相關來信。專案方強調，curl 平時就不接受透過電子郵件提交漏洞通報，這項原則在休假前後都不變。
作者 Daniel Stenberg 表示，curl 維護者過去數月承受大量漏洞通報壓力，需要真正休息、減少壓力並享受夏天。GitHub 上的 issue 與 Pull Request（PR，程式碼變更提交流程）仍會照常開放；但因 8 月初可能累積待處理事項，原訂版本 8.22.0 的發布時程也順延兩週，改到 2026 年 9 月 2 日。若有緊急需求，文章明確指出可購買付費支援合約；既有付費支援客戶在這段期間仍會取得完整且適當的服務。
Hacker News 討論多數肯定這項決定，認為開放原始碼維護者長期承受高壓、回報有限，暫停一個月是合理的人性化安排。有人特別引用「壞人不會休息？也許不會，但我們會」這段文字，認為在高度技術化且常忽略人的工作環境中，這是一種必要的界線。也有留言提到，FOSS（Free and Open Source Software，自由與開放原始碼軟體）維護者如今還面臨 LLM（Large Language Model，大型語言模型）產生的大量合併請求，讓審查與管理負擔進一步增加；付費客戶仍有服務，已經足以區分免費使用與商業支援。
也有不同觀點指出，curl 這類基礎網路工具被全球大量系統依賴，卻仍高度仰賴少數維護者，顯示開放原始碼基礎建設的資金與備援機制不健全。不過其他人回應，文章已清楚說明付費支援合約仍可處理安全事件；若組織真的需要即時保證，就應購買支援或自行投入人力修補。另有討論提到負責任揭露（responsible disclosure）問題：若 7 月發現漏洞是否可以直接公開？部分留言認為通常至少應給維護方約 90 天處理時間，不能因暫停通報一個月就視為可立即公開。
討論串也延伸到維護工作的實際規模。有人提到 Daniel 曾表示自 2019 年起全職投入 curl，常一週工作 50 小時以上；其他留言指出，curl 是龐大且複雜的程式碼庫，日常工作包含測試套件、文件更新、錯誤修正與維護雜務，不只是新增功能。也有人從瑞典勞動文化角度補充，瑞典重視夏季長假，連續四週休假相當常見。整體而言，社群氣氛偏向理解與祝福，同時也把問題拉回更大的結構性議題：關鍵開放原始碼專案若被全世界依賴，就需要更成熟的資金、支援與人力安排。
👥
26 則討論、評論 💬
https://news.ycombinator.com/item?id=48537165