curl 作者 Daniel Stenberg 在博客中宣布，以后将不再向各 Linux 发行版的邮件列表发送有关 cURL 安全漏洞的提前预告。

Daniel Stenberg 从 2011 年开始向发行版邮件列表（当时称为 linux-distros）发送有关"已发现但未解决"的 curl 安全漏洞的“预先通知”。通过提前通知各发行版，让他们可以抢先一步修复 curl 包。如此一来，在 curl 解决并公布安全漏洞的同时，各发行版就可以提供同步的 curl 升级和修复。

但最近 curl 项目更新了安全流程，以前 curl 会在发版日期的 48 小时内将修复程序合并到普通的公开 PR，48 小时足以完成所有已知问题的测试和 CI 验证修复。但如果出现了新的安全问题，要赶在版本发布之前测试并修复新问题，48 小时则是一个非常短的时间窗口。

为了有更多的时间来处理漏洞的修复，在新的 curl 安全流程中，如果安全问题是“低严重性或中等严重性”，将允许更早地将修复程序提交到公共 PR 中。而且 PR 中不能详细讨论安全问题的细节，只能描述用于哪个漏洞。

当然，这样做也有风险，一些别有用心的人会在“提交安全 PR —— 发版修复”这段真空期内钻漏洞，所以这种方法只能用在严重程度为低和中等的安全问题上，高风险的安全漏洞则完全不能公开。

在 curl  发布 8.0.0 版本的前一周，Daniel 仍然再次向发行版的邮件列表发送电子邮件，通知他们 curl 即将向全世界公开的六个漏洞。但这次双方的规则产生了冲突：curl 新的政策导致，在通知各发行版的时候，这些安全问题已经在公共的 git 存储库中提交了修复程序，而按照发行版邮件列表的政策规定，公开的安全问题则属于”禁运“的话题。

许多发行版都有”禁运“规则，只能在安全漏洞”发布日期的 10 天“以内将安全问题发送到公开的邮件列表中，距离安全漏洞发布日期超过十天，则不允许公开安全漏洞。

此外，如果安全问题已经有公开提交的修复代码，他们会认为该安全问题是公开的，也属于“禁运“的安全问题。

在双方的政策发生冲突后，发行版的团队要求 curl 不能再发送这类公开的安全问题到其邮件列表中。对于 Daniel 来说，这就纯纯减轻了工作量，因为 curl 基本没有等级超过中等的安全问题，大部分安全问题都会提前合并 PR ，违反了发行版的”禁运“规则。

而对于 curl 用户，这个改动则意味着他们将来从发行版中获得带安全补丁的 curl 版本的时间会稍微慢一些。