所有已知的和公开的curl或libcurl相关漏洞,都列在curl网站安全页面.
安全漏洞不应该进入项目的公共bug跟踪系统,除非必要的限制访问的问题的配置,报告和项目的安全团队.
处理新安全漏洞的典型过程如下.
在该过程结束之前正式公布之前,不应公布任何有关漏洞的信息.这意味着,例如,一个bug跟踪条目,不能创建跟踪问题自会让问题公开,不应该在任何项目的公共邮件列表讨论.同时信息与任何承诺不应该提及,如果公开宣布前做的安全性.
-
发现问题的人,报告,私下报告漏洞.
curl-security@haxx.se. 这是一个电子邮件的别名,它能让少数人选择和信任. -
报告或管理的未公开信息,其中无关curl或libcurl中的安全漏洞的消息 将被忽略，无需进一步操作
-
安全团队中的一个人会发送电子邮件给原始用户,以确认报告.
-
安全小组调查报告,要么拒绝,要么接受.
-
如果报告被拒绝,团队写信给用户解释原因.
-
如果报告被接受,团队写信给用户让他/她知道这是被接受的,他们正在努力解决问题.
-
安全团队讨论问题,解决问题,考虑问题的影响并提出发布时间表.这个讨论应该尽可能多地涉及用户.
-
信息的发布应该是"尽快"的,并且通常与包含补丁的即将发布的版本同步.如果用户或其他任何人认为下一个计划发布的时间太远,那么出于安全原因,应该考虑单独提前发布.
-
编写一个关于问题的安全建议草案,解释问题是什么、它的影响、它影响的版本、任何解决方案或解决办法,以及修复发布时,确保正确地信任所有贡献者.
-
请求distros@openwall的CVE号码, 在通知和准备他们即将发布的公共安全脆弱性公告时,附上咨询草稿以供参考.请注意,"distros"不接受禁令超过14天.
-
用CVE号更新"安全咨询security advisory".
-
安全团队在私有分支中提交修复.提交消息应该理想地包含CVE编号.此修复通常也被分发到"distros"邮件列表,以允许他们在公告之前使用修复程序.
-
在下一个发布的当天,私有分支合并到主分支并被推送.一旦被推,公众可以访问该信息,并且实际发布应立即跟进.
-
项目团队创建一个包含修复的版本.
-
项目团队宣布了该版本的发布和漏洞 我们总宣布发布的相同方式 - 被发送到 curl-announce，curl-library和curl-users邮件列表。
-
网站上的安全网页应该得到所提到的新漏洞.
谁在这个名单上? 有几个标准你必须满足,然后我们可能会要求你加入名单或你可以要求加入它.真的不是很正式.我们只要求你在curl项目有一个长期的存在和你的项目和工作方式的理解.你一定在附近待了很长一段时间,你不应该在不久的将来消失.
我们不会让参与者名单公公开, 主要因为它往往有所不同, 随着时间的推移,列表只有带来风险.