Security

Security is a primary concern for us in the curl project. We take it seriouslyand we work hard on providing secure and safe implementations of all protocolsand related code. As soon as we get knowledge about a security related problemor just a suspected problem, we deal with it and we attempt to provide a fixand security notice no later than in the next pending release.

We use a responsible disclosure policy, meaning that we prefer to discuss andwork on security fixes out of the public eye and we alert the vendors on theopenwall.org list a few days before we announce the problem and fix to theworld. This, in an attempt to shorten the time span the bad guys can takeadvantage of a problem until a fixed version has been deployed.

Past security problems

During the years we have had our fair share of security related problems. Wework hard ondocumenting everyproblem thoroughly with all detailslisted and clearly stated to aid users. Users of curl should be able to figureout what problems their particular curl versions and use cases are vulnerableto.

To help with this, we presentthis waterfallchart showing how allvulnerabilities affect which curl versions and we have this complete list ofall known security problems since the birth of this project.

Backdoors and supply chain risks

With libcurl being installed and running in billions of installations all overthe world and in countless different environments, we recognize that it is anideal target for someone who wants a backdoor somewhere.

A new or old maintainer might at any point propose a change that soundsinnocent and well-meaning but has a disguised malicious intent.

To mitigate such risks, we apply established procedures and techniques:

• GitHub. The curl project useshttps://github.com/curl/curl as its mainsource code git repository since 2010. We rely on their hosting to secureaccess as per our configuration.
• 2FA required. We require all maintainers with push access to git to havetwo-factor authentication enabled, to reduce the risk that attackers canimpersonate them and use their credentials to push source code changes. Werely on GitHub's 2FA setup.
• Reviews. Every contribution that are proposed for inclusion in theproject is reviewed by a maintainer. All changes are always done publicly inthe open to allow all interested parties to participate. No invitationneeded. All changes are also automatically checked, tested and scanned bynumerous tools before accepted.
• Readable code. We believe in readable code that follows our code style.Easy to read makes it easy to debug. If code is hard to read it should beimproved until it gets easy to read. With easy to read code, smugglingmalicious payloads or hiding nefarious functionality is excruciatingly hard.
• Tests. We have a large test suite that is always growing and we do notaccept changes that break existing tests and new functionality need to bringnew tests for the new functionality. We runseveral hundred thousandstests on each proposed changed to make sure existing functionality remains.This includes fuzzers, static code analyzers, fault injectors and more.
• No binary blobs. All files stored in version control, in the gitrepository is readable or is otherwise small and documented. There is noplace anywhere for any hidden encrypted payload. We run a scanner on allfiles on every change to detect binary files and the few files that need toremain looking binary are manually vetted and verified against a checksum.
• Reproducible builds. curl releases are shipped as tarballs that arehosted on the curl website (https://curl.se). We provide documentation,docker setups and configurations etc to allow anyone wanting to easilyreproduce our release builds to generate identical images - proving thatwhat we ship is only contents taken from the git repository plus othercorrect and properly generated contents.
• Signed commits. Over 90% - not all - of recent commits were signed tohelp prove provenance. Signing commits is not yet a mandatory requirementfor committers but we hope to gradually increase the share over time andmake it mandatory soon.
• Signed releases. Every release, every uploaded tarball, is signed byDaniel. This helps to prove that the files have not been tampered with sincethey were produced. We have opted to not sign them by multiple persons onlybecause of the added complexity for the relatively small extra protection.
• Signed tags. Every release is generated from the exact state of the gittree where a correspondingsigned tag is set. The name of the release tagis the same as the release version.
• Fix all vulnerabilities quickly. Whenever we receive a securityvulnerability report, we create and ship a fix in the next pending release.Sometimes sooner than previously planned. Only in extremely rare cases doesit take longer than a release cycle, but in the name of accuracy andcorrectness we do reserve the right to spend time on research to get itright. With every fixed security vulnerability we release a detaileddescription of the flaw including exact commit that introduced the problem,recommendations for users and more. Further, the security advisories getannounced to the world.