谷歌为Libcurl工作提供的资助

今年早些时候，我获得了一笔谷歌补丁拨款，明确表示要提高libcurl的安全性。

这是谷歌计划的一笔预付款，该计划将自己描述为“一个奖励对选定的开源项目进行主动安全改进的试验性计划”。

我接受了CURL项目的这笔拨款，我打算继续为确保CURL的安全而努力。我认识到cURL安全的重要性，因为cURL仍然是世界上使用最广泛的软件组件之一，甚至是正在进行网络数据传输的组件，这通常是一项有风险的业务。在平均每天通过互联网完成的所有互联网传输中，CURL负责相当大的份额。我的工作是确保这些转账尽可能安全可靠。当然，这不是我唯一的责任，因为我还有其他任务要做，但仍然如此。

在CURL项目中，安全已经是并且始终是最重要的，对我个人来说也是如此。当然，这笔拨款将进一步推动我加强cURL的努力，并通过联合来加强它的所有用户。

当提到与curl相关的安全性时，有些人喜欢提及并宣传其他编程语言，但是curl不会用另一种语言重写。相反，我们将更加努力地编写良好的C语言，更早更好地检测代码中的问题。

字符串和缓冲区大小限制-libcurl中允许增长的所有字符串输入和所有缓冲区现在都有一个允许的最大大小，这是有意义的。这可以阻止可能使事情发展失控的恶意使用，并有助于检测会导致相同问题的编程错误。此外，通过确保字符串和缓冲区永远不会大得离谱，我们可以更好地避免整类整数溢出风险。

统一的动态缓冲区功能-通过减少处理“不断增长的缓冲区”的不同实现的数量，我们降低了其中一个缓冲区出现错误的风险，即使它很少使用或模糊器很难到达和“锻炼”的地方也是如此。“dynbuf”内部API在curl 7.71.0(2020年6月)中首次发布。

Realloc缓冲区增长统一-与前一个几乎相同，但在我们历史的早期，当我们使用愚蠢的realloc()处理时，我们遇到了几个问题，这可能会导致不好的事情。通过限制字符串大小和统一缓冲区函数，我们减少了使用realloc的位置数量，从而减少了出现新realloc错误的位置数量。重新分配错误通常与整数溢出结合在一起。

代码样式-随着时间的推移，我们逐渐改进了我们的代码样式检查器(checksrc.pl)，我们也逐渐使我们的代码样式更加严格，导致代码、空格和命名的变化较少。我坚信这会使代码看起来更连贯，因此更具可读性，从而减少错误，更容易调试代码。它还使grep和搜索代码变得更容易，因为您需要扫描的变体更少。

更多的代码分析器-我们通过大量的代码分析器运行每个提交和PR，以帮助我们及早发现错误，并且我们总是删除检测到的问题。撰写本文时使用的分析器：lgtm.com、Codacy、Deepcode AI、Monocle AI、clang tidy、Scan-Build、CodeQL、Muse和Coverity。当然，这还不包括运行整个测试套件的常规运行时工具，如valgrind和saniizer版本。

内存安全组件--CURL已经支持使用过多的不同库和“后端”来构建，以满足用户的需求和愿望。通过适当地支持并向用户提供用Ruust等编写的组件(或帮助开发人员避免陷阱的其他语言)进行构建，未来的curl和libcurl构建可能会潜在地避免整个部分的风险。(请在不久的将来继续关注有关此主题的更多信息。)。

认识到无论我们做什么，不管我们经营得多么紧张，我们都会继续偶尔滑倒，这一点很重要，我们应该确保尽可能好地及早发现并修复这些失误。

提高赏金。虽然不是直接修复问题，但在我们的漏洞赏金计划中提供更多的资金有助于我们获得安全研究人员的更多关注。我们的目标是温和地提高奖励金额，逐步提高到每个漏洞可能数千美元，只要我们有资金支付，并且我们管理将安全漏洞保持在合理的低频率。

更毛茸茸的。我以前说过，但让我再说一遍：一旦我们修复了我们使用的静态分析器指出的所有缺陷，模糊确实是发现curl中问题的最好方法。CURL的主要模糊是由OSS-Fuzz完成的，它不知疲倦地不停地敲打最新的curl代码。

好的模糊需要一定程度的“牵手”，才能真正测试所有的API并挖掘最肮脏的角落，我们应该致力于在libcurl中添加更多的“探针”和入口点，让Fuzzer使用更多的代码路径来潜在地检测更多的错误。