I added a section to everything #curl about what we do to mitigate backdoor attempts:
https://everything.curl.dev/project/security.html#backdoors-and-supply-chain-risks
Did I forget anything obvious?
Security - everything curl
everything there is to know about curl, libcurl and the cURL projecteverything.curl.dev
This website is tracked using the Matomo analytics tool. If you do not want that your visits are logged in this way you can set a cookie to prevent Matomo / Piwik from tracking further visits of the site (opt-out).
ティージェーグレェ
in reply to daniel:// stenberg:// • • •Missed anything obvious?
#Alt4You ;)
Text reads:
"Backdoors and supply chain risks
With libcurl being installed and running in billions of installations all over the world and in countless different environments, we recognize that it is an ideal target for someone who wants a backdoor somewhere.
A new or old maintainer might at any point propose a change that sounds innocent and well-meaning but has a disguised malicious intent.
To mitigate such risks, we apply established procedures and techniques:
2FA required. We require all maintainers with push access to git to have two-factor authentication enabled, to reduce the risk that attackers can impersonate them and use their credentials to push source code changes.
Reviews. Every contribution that are proposed for inclusion in the project is reviewed by a maintainer. It is also automatically checked, tested and scanned by numerous tools.
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 be improved until it gets easy to read. With easy to read code, smuggling malicious payloads or hiding nefarious functionality is excruciatingly hard.
Tests. We have a large test suite that is always growing and we do not accept changes that break existing tests and new functionality need to bring new tests for the new functionality. We run several hundred thousands tests 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 git repository is readable or is otherwise small and documented. There is no place anywhere for any hidden encrypted payload."
(1/2)
Arjan van de Ven
in reply to daniel:// stenberg:// • • •Seth Michael Larson
in reply to daniel:// stenberg:// • • •Looks really great!
The only thing that comes to mind is reproducible builds are only useful to detect injection if someone actually tries to reproduce the builds. Bystander effect says no one likely is, so adding a separate (perhaps GitHub Actions?) build to confirm an identical tarball SHA would remove the possibility that your own environment is compromised.
daniel:// stenberg://
in reply to Seth Michael Larson • • •Ben Reser
in reply to daniel:// stenberg:// • • •Have multiple maintainers/community members sign the tarballs. As things stand now the confidentiality of your lone key stands between a modified tarball being published and potentially not caught for a while. That modified tarball will not match git but users pretty much never compare the tarball to git. When the other maintainers/community members sign for the release they can compare the tarball to git and use their signature to assert that the tarball matches git. Users that do verify signatures will notice if only one signature is there or if all the signatures don't match and it will start being investigated, potentially reducing the scope/timeframe of the compromise.
I helped design the Subversion project's release process and the project does this. Releases require a certain number of votes/signatures and the release announcement has a list of who signed and the fingerprints for their keys. You can see that project documentation for the signing here: https://subversion.apache.org/docs/community-guide/releasing.html#tarball-signing You can see an example of a release announcement which is made on the announce mailing list and is mirrored here: https://lists.apache.org/thread/gcbmxzyssxk4693c7lcwv8yp1lfhsg7g
Subversion doesn't produce official builds but if they did and had reproducible builds then builds could be reproduced and folks verifying that the builds match the tarball/git could provide signatures for them as well. Which would help resolve @sethmlarson's point about reproducible builds not being helpful unless someone is trying to reproduce them.
Apache Subversion - Community Guide - Making Subversion Releases
subversion.apache.orgdaniel:// stenberg://
in reply to Ben Reser • • •kurtseifried (he/him)
in reply to daniel:// stenberg:// • • •You mention "git repository" but not where they are, e.g. I'm pretty sure it is https://github.com/curl/ but I could be wrong (e.g. https://github.com/redhat is not redhat). The git repo is mentioned in other docs but the organization never is:
No results found for site:curl.dev "https://github.com/curl/".
Regarding "2FA required" is it possible to list what kind of 2FA is/is not supported (e.g. SMS? app? hardware token?).
Regarding reviews I would suggest adding that most code is proposed publicly (all code? do you do embargoed security fixes in private? I don't know) and as such anyone and everyone can potentially weigh in on it. If you do embargoed security fixes in private it might help to mention which group (e.g. core devs?) reviews those fixes.
Regarding "Signed commits. Some - not all - of the committers sign commits to help prove provenance." is there a long term plan to get it all signed? Is it a voluntary thing? Critical commits? Some clarification here would help because it's a bit confusing/raises more questions than it answers.
Regarding "Fix all vulnerabilities quickly. Whenever we receive a security vulnerability report, we create and ship a fix in the next pending release." it might help to clarify if this has ever resulted in a delay, e.g. in the Linux Kernel world we've had flaws that took the better part of a year to sort out (hardware stuff mostly), some clarification/reassurance here might be good.
You're already way more transparent/forthcoming than most projects but you may as well turn it up to 11.
curl
GitHubdaniel:// stenberg://
in reply to kurtseifried (he/him) • • •project/security.md: expand on details by bagder · Pull Request #500 · curl/everything-curl
GitHubThorsten Heit
in reply to daniel:// stenberg:// • • •Florian Margaine
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Florian Margaine • • •Florian Margaine
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to daniel:// stenberg:// • • •alexanderkjall
in reply to daniel:// stenberg:// • • •vsz
in reply to daniel:// stenberg:// • • •gen-keys: add scripts to generate secrets by vszakats · Pull Request #70 · curl/curl-for-win
GitHubChris Carr
in reply to daniel:// stenberg:// • • •Spindel
in reply to daniel:// stenberg:// • • •