curl 将在 2026 年 7 月不接受漏洞报告

总体反应

• 许多评论者支持 curl 维护者休息一个月、不处理漏洞事务，认为这健康、人性化，而且早就该这样做了。
• 一些人认为这是一种巧妙的表达方式，既让“休假”变得正常，也在宣传商业支持。
• 也有人觉得这有点“奇怪”或有风险，但仍然接受他们需要休息。

付费支持与“自己修好它”

• 强调 curl 是自由软件，不提供任何担保；需要保证的用户应该购买支持合同。
• 多位评论者指出，由于源码可用，组织可以：
  • 自行修补问题。
  • 维护一个临时分支。
  • 之后再把补丁上游合并。
• 也有人回应说，长期维护分支并在整个生态中整合补丁的成本很高，而且不现实。

安全与披露方面的担忧

• 有人担心攻击者会利用这个“安静的月份”，或者专门在那时集中寻找零日漏洞。
• 也有人反驳：
  • 真正严肃的攻击者本来也不会依赖项目的接收流程。
  • 在像 curl 这样成熟的项目里，影响重大的漏洞本来就很少见。
• 关于“负责任披露”存在争论：
  • 一方认为仍应等待（例如 90 天通常是常见做法），或者至少再等一个月。
  • 另一方认为，如果漏洞正在被积极利用，那么公开披露并附上最小补丁也许是合理的。
  • 还有人指出，这里只有社区惯例，没有硬性规则。

工作与生活平衡，以及休假文化

• 很长的讨论串赞扬工作与休息的严格分离，包括：
  • 把工作设备留在一边，或在技术上阻止访问。
  • 明确反对或惩罚员工在休假期间工作的管理者。
• 欧洲评论者描述了 4 周以上假期、病假保护，以及支持真正断联的法律和文化背景。
• 其他人分享北美语境，说明这种边界在职业早期更难建立，但在资深层级会更可行。

OSS 系统性与资金问题

• 有人担心关键基础设施依赖少数资金不足、又没有后备支持的人。
• 一些人认为用户在“消费”OSS 却不付费，却又期待企业级 SLA。
• 讨论还提到，像 AI 工具这样的热门项目往往获得远比 curl 这类无聊但必要的库更多的资金。

技术侧记

• 简要提到 AI 工具发现 curl 漏洞、Rust 重写比听起来更难，以及形式化方法或隔离等替代方案（例如沙箱、类似 Qubes 的隔离）。