4 篇内容
curl 维护者在 2026 年 7 月实施“bliss 之夏”，暂停所有漏洞报告处理一个月。文章详细记录了这次决策的背景、过程与效果：团队立即感受到减压与自由，得以处理积压的代码、功能、文档等长期忽略的工作，重新找回开源乐趣；付费客户未受影响，外部社区反应积极，甚至有其他项目效仿。作者也讨论了 CNA 规则下的应对、安全风险感知以及休假可能导致的报告堆积，并计划后续分享影响。整体来看，这次主动暂停让团队恢复了精力与热情，几乎没有负面影响，未来可能继续推行。
推荐收录，因为它提供了一个难得的开源项目主动暂停安全响应的真实案例，展示了维护者从高压中恢复的路径和积极结果。文章对“长期可持续维护”有直接启示，适合开源维护者、项目管理者及关注工程师倦怠的读者，其决策逻辑与效果评估可迁移到其他关键基础设施项目的维护实践中。
这篇文章基于 curl 项目累计处理上千份漏洞报告的经验，系统总结了“优秀漏洞报告”应具备的要素。作者强调，提交者首先要确认问题是否真实、是否超出文档已说明的行为，并按项目要求的渠道提交，避免给维护者增加不必要的沟通成本。报告正文应先用简短、人写的段落概括问题与影响，再附上可独立运行的复现脚本或源码，并尽量提供可帮助理解和修复的补丁。文章还指出，报告应注明测试版本、尽可能定位最早受影响版本，并在后续沟通中持续协作，帮助项目完善修复与安全公告。整体内容适用于安全研究员、开源维护者和想提升漏洞通报质量的工程师，但它主要讨论报告流程与协作规范，而非漏洞挖掘技术本身。
推荐收录，因为文章直接来自长期处理漏洞报告的开源项目维护者，证据充分，且给出了复现、补丁、版本定位和协作的具体要求。对安全研究员、开源项目维护者以及负责漏洞响应的工程师都很实用，能直接迁移到真实提报与处置流程中。
文章围绕 curl 在处理 URL 主机名尾随点（trailing dot）时暴露的三个新问题展开：IPv4 数字地址、双尾随点与 Cookie/PSL 校验。作者说明了尾随点会干扰 inet_pton、HSTS 逻辑和 libpsl 公共后缀判断，进而导致把数字地址误判为主机名、使非法双点主机进入内部流程，甚至让本应被拒绝的超级 Cookie 被接受并触发 CVE-2026-8924。文中给出了 curl 8.21.0 的修复思路，包括对单个尾随点做归一化吞掉、对双尾随点直接禁止，以及同步修补相关安全检查链路。它体现了 URL 规范、DNS、TLS、Cookie 安全与库间接口细节之间的耦合风险，但也承认对“尾随点应报错还是容错”的边界仍存在争议。
收录价值明确，因为文章直接展示了一个看似细小的 URL 语法差异如何穿透解析、TLS、HSTS 和 Cookie 安全链路并引发漏洞。适合做网络协议实现、客户端安全和库兼容性设计的参考，尤其能帮助读者理解规范容错与安全收紧之间的取舍。
这篇文章记录了 curl 作为 CNA 后首次遭遇的 CVE 争议，核心是作者如何判断一个安全报告是否应被赋予 CVE，以及为何认为该问题低于“LOW”级别。文章详细说明了漏洞触发链路：必须使用以点开头的非法主机名、依赖本地地址解析或特殊环境、还要命中特定 TLS 后端与通配符证书检查缺陷，因此作者主张它更像一个已修复的 bug，而不是值得全生态响应的安全漏洞。最终 MITRE 认可了 curl 的判断，未分配 CVE，文章也由此展示了 CNA 视角下的漏洞分级、风险判断与争议处理流程。
推荐收录，因为它不仅讲一个单点 bug，而是完整展示了开源项目如何做漏洞评估、如何在“是否发 CVE”上做取舍，以及为什么“理论上可触发”不等于“值得全生态警报”。这类经验对安全响应、CNA 协作、漏洞分级和开源维护都具有很强的迁移价值。