12 篇内容
文章是 curl 作者 Daniel Stenberg 对项目三十年的第一人称回顾，从 1996 年约百行的 httpget 0.1 讲到 curl 4.0、libcurl 与数十亿级安装量。核心并非协议实现细节，而是长期维护方法论：可移植 C、宽松许可证、持续迭代而非重写、保持 API/ABI 兼容、透明治理、完善文档、独立于公司并参与 IETF。作者也坦承 BDFL、单一维护者依赖、开源资助困难及维护者被误认作攻击者等风险，并认为 curl 的优势来自数十年稳定交付和生态信任。边界是个人叙事与经验总结，缺少系统数据和可复现实验，不能替代协议实现或治理研究。
推荐收录：文章以 curl 三十年的一手经历给出了可验证的长期维护原则——不重写、API/ABI 稳定、透明文档和独立治理，并直面 BDFL 与资助风险。适合开源维护者、基础设施工程师和工程负责人参考；局限是个人回顾，技术实现细节较少，需结合项目文档与代码阅读。
文章介绍 curl 项目将 LOW 和 MEDIUM 级别漏洞处理转为公开流程，并说明社区如何参与监督和评估。漏洞报告直接提交到 GitHub issue，维护者先用 vuln:ASSESS 标记待评估问题，再根据结论改为 vuln:NONE、vuln:LOW 或 vuln:MEDIUM，并允许社区提出反对意见和证据。确认的漏洞会分配 CVE，并在 curl-www 仓库编写包含描述、CWE、影响版本和 curl 区域等信息的公告，与修复版本同步发布。文章还区分“公开”和“发布”：问题较早出现在仓库中，但直到包含修复的 curl 版本发布时才进入 CVE 数据库并被外部工具广泛获取。该流程强调透明和可复核，但主要适用于 curl 的低中危漏洞，未涉及高危漏洞的保密协调细节。
推荐收录。文章以 curl 的真实流程展示了开源项目如何公开评估漏洞：标签状态机、CVE 与公告模板、公开与发布的时间差都写得很具体，可直接用于设计或评审开源安全响应流程。适合开源维护者、安全响应人员和安全工程读者；局限是仅覆盖 curl 的低中危处理，不包含高危漏洞的保密协调和完整技术取证。
文章围绕开源项目 curl 如何应对 AI 参与的漏洞报告展开，反驳“直接忽略 AI 垃圾”的建议。作者指出，报告即使由 AI 生成，也可能揭示真实漏洞，忽略会让用户暴露于风险；开源项目虽无法律担保，但质量声誉和商业支持合同构成实际义务。自 2026 年春季起，curl 收到的幻觉式低质报告已基本消失，当前挑战变成高数量、高质量但极其冗长的报告。AI 仍难判断 bug 与漏洞边界及严重级别，却常能生成可用的复现和 PoC，且近几个月每份报告都涉及 AI。该判断基于维护者一手经验，并非系统量化研究。
推荐收录，因为作者以 curl 维护者身份给出直接经验：AI 生成的漏洞报告已从大量幻觉转向高数量、高质量但冗长，且近几个月所有报告都涉及 AI。对开源维护者、安全响应和漏洞治理读者，文中关于不能忽略真实漏洞、报告沟通成本和 PoC 价值的判断可迁移到类似项目；但它是单项目主观观察，缺少量化数据。
文章宣布 curl 从 2026 年 10 月 26 日起调整漏洞披露流程：被判定为 LOW 或 MEDIUM 的报告改为在 GitHub 公开提交和讨论，仅 HIGH/CRITICAL 保留在 HackerOne 私密处理。作者把这一变化归因于漏洞报告数量激增和维护者不堪重负，并说明公开化可让社区参与评估、修复、编写公告和帮助发行版提前跟进。文章也承认公开会扩大恶意利用窗口、可能误判严重级别等风险，并讨论 LOW 漏洞的 CVE 申诉、拒绝无现实影响的“疯狂组合”以及 AI 生成报告带来的压力，最后提到 curl 的四级严重性划分和指南。
推荐收录，因为这是一份由 curl 维护者给出的第一手安全流程变更说明，明确交代了 LOW/MEDIUM 公开、HIGH/CRITICAL 私密的规则、维护者过载的现实约束，以及开放协作与攻击窗口扩大之间的取舍。适合安全工程师、开源维护者和依赖 curl 的团队阅读，可迁移到漏洞分级、披露流程和社区协作设计中；主要风险是它属于项目政策公告，具体规则可能随实践调整。
curl 作者 Daniel Stenberg 回顾项目许可证从 GPL、MPL 到 MIT 的演变，并说明 2002 年后 curl 实际使用的 MIT 文本曾被小幅修改，因此并非标准 MIT。SPDX 后来为这一修改版分配了独立的 “curl” 许可证标识，作者也承认多年来仍习惯称其为 MIT 以免增加理解成本。2026 年 4 月 17 日 OSI 正式批准 curl license，使其获得官方开源许可证认可，作者认为这在实际采用上未必改变很多，但具有象征意义。文末附上 curl license 全文，包括版权声明、授权条款和免责声明。文章属于项目方的第一手许可历史记录，但对法律兼容性和 OSI 批准流程本身没有展开分析。
推荐收录，因为它以第一手视角记录了 curl 从 MPL/MIT 到修改版 MIT、SPDX 独立标识再到 OSI 批准的完整许可演变，并附上许可证全文，可直接用于理解 curl 项目的许可现状与合规边界。适合开源维护者、依赖 curl 的开发者以及关注开源许可证治理的读者参考。局限是篇幅较短，未展开法律兼容性或 OSI 审批标准的系统分析。
文章由 curl 作者 Daniel Stenberg 总结 curl 8.23.0 中一批性能与内存优化，源于项目新搭建的性能测试图表。优化覆盖 base64 编解码、URL 百分号编解码、日期解析、URL 解析、内部 printf 和数字解析，并大幅缩小 easy、multi、connectdata 等核心结构体，减少单次 HTTP 下载的分配次数与峰值内存。作者给出具体加速比例和内存数据，例如 URL 编码约快 4 倍、连接结构体缩小超 40%、排除下载缓冲后内存少 15%。这些改动对多数普通传输不会带来肉眼可见差异，更适合作为持续优化和基准驱动改进的工程记录；文章偏结果汇总，未展开实现细节、取舍和失败边界，相关测试已放入仓库供复现。
推荐收录：文章来自 curl 维护者，给出了可验证的性能与内存改进数据，包括解析函数加速、结构体瘦身和分配峰值下降，能直接作为 C 网络库性能优化与基准驱动开发的参考案例。适合性能工程师、开源维护者和 libcurl 使用者阅读；不足是偏结果清单，缺少深度取舍分析，读者需结合仓库测试和代码补足实现细节。
文章由 curl 作者 Daniel Stenberg 撰写，针对一家大型电力基础设施公司的 IT 人员提出的 libcurl.dll 升级请求作出回应。作者解释该 DLL 并不是 Windows 自带组件，而是某个应用安装时放入 system32 的；Windows 内置的 curl 使用静态链接，因此不会产生该文件。由于无法获知此 DLL 的确切构建方式，盲目替换为最新版很可能导致依赖它的应用崩溃。作者建议先用 tasklist 等工具找出使用该 DLL 的应用程序，再联系相应厂商进行更新。文章还澄清了静态链接与动态链接的差异，以及漏洞扫描器在第三方组件供应链场景中的局限性。最后介绍了 curl 项目提供的长期稳定版本和构建建议，但明确表示无法代替厂商进行运行时补丁。
推荐收录。这是 curl 维护者基于真实案例对 libcurl.dll 分布与更新困境的权威说明，直接纠正了“直接替换 DLL 即可修复漏洞”的常见误解。适合系统管理员、安全人员和应用开发者阅读，有助于理解动态链接库的依赖管理边界、供应链漏洞扫描的盲区，以及“谁构建、谁负责更新”的处置原则。文中给出的排查思路和长期支持方案，对处理类似第三方组件漏洞问题有可迁移价值。
本文是 curl 项目维护者 Daniel Stenberg 发布的博客，介绍为 curl 新建性能测试系统的过程和设计思路。作者从零开始搭建了一套自动构建与测试流程：每二十分钟通过 cron 触发脚本，自动更新代码、构建并运行多种性能测试，汇总后生成图表并发布到 curl 官网。文章详细说明了如何用 gnuplot 生成可视化、用箱线图展示数据分布，以及引入“stakes”阈值来识别性能回归，并尝试用 Mann-Kendall 趋势检测辅助分析。作者也坦诚地讨论了方案的局限：测试结果依赖特定本地硬件和环境，短期内更适合发现细微回归，长期数据需要重新设计。文中还展示了优化分配数与结构体大小之间的权衡实例。
推荐收录。文章呈现了一个真实开源项目从零搭建性能监控系统的完整工程案例，包含脚本化构建、数据可视化、回归阈值设定等可复现实践，且强调了“先做起来再完善”的务实思路。对于需要建立持续性能跟踪的开发者或维护者，文中关于测试环境、数据展示和权衡取舍的经验具有直接可迁移价值。
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 协作、漏洞分级和开源维护都具有很强的迁移价值。