curl项目公开处理中低危漏洞并邀请社区参与评估

我最近写了一篇博客，讲的是curl项目如何转为在公开场合处理所有严重程度为LOW和MEDIUM的漏洞。现在我来描述一下你可以如何跟进这个过程并做出贡献。添加你的观点、评论和评估，帮助curl项目保持诚实、做得更好并管理好负载。

漏洞报告现在直接提交到curl在GitHub上的issue tracker。从最初收到的一批来看，提交者在标题中并没有特别突出安全角度，而是在issue描述中暗示或说明。我希望如果我们在某种程度上漏掉了，人们能有所反应。

我们使用一组标签来管理GitHub上的漏洞报告。它们都以vuln:为前缀。

每一个提交的、声称或疑似具有安全角度的issue——即一个可能的漏洞——首先会被（curl维护者之一）打上vuln:ASSESS标签。这个标签将该issue标记为我们应当先评估、判定它是否是一个漏洞，如果是，严重程度如何。任何人都可以自由留下评论和想法，帮助我们得出结论。评估完成后，这个标签会被移除。

这个issue已就其漏洞风险进行了评估，我们认为它没有风险；或者风险非常低，被认为低于LOW严重程度。这个issue仅作为普通bug处理。如果有人反对并提供了合理且有说服力的论据，我们可以重新评估。

这个issue是一个已确认的LOW严重程度漏洞。我们为此开发修复，一旦可用就合并，然后关闭这个issue。如果有人对严重程度有异议并提供了合理且有说服力的论据，我们可以重新评估。

这个issue是一个已确认的MEDIUM严重程度漏洞。我们为此开发修复，一旦可用就合并，然后关闭这个issue。如果有人对严重程度有异议并提供了合理且有说服力的论据，我们可以重新评估。

已确认的漏洞会获得一个CVE和一个专门的安全公告，我们在curl-www仓库中与issue及其修复分开处理。CVE及其公告会与待发布的curl版本同步发布。在此之前，它们作为进行中的open pull-request保留，使用vuln:LOW或vuln:MEDIUM标签。

每个公告都包含关于单个curl漏洞的所有信息。详细描述、所有信息、CWE、CVE、受影响的版本范围、是否是C语言错误、发生在curl的哪个“区域”、指向原始报告的链接，等等。其理念是，这一个markdown文件包含任何人可能想要和需要关于这个特定漏洞的所有必要信息。

这些漏洞的工作是即时公开的，我们为一问题注册并分配CVE Id（实际的数字标识符）的那一刻，你就可以了解到它的存在。

然而，我们直到发布日才会将issue及所有相关元数据发布到CVE数据库，发布日与curl发布日相同，即我们发布包含该漏洞修复的第一个版本的那一天。

所以信息早期就在curl仓库中公开，但可能要到几周之后才会正式发布，而正是在那个较晚的时刻，它才会被其他工具和生态系统获取，然后被广泛知晓。