Forgot 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)

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.

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: subversion.apache.org/docs/com… You can see an example of a release announcement which is made on the announce mailing list and is mirrored here: lists.apache.org/thread/gcbmxz…

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.

You mention "git repository" but not where they are, e.g. I'm pretty sure it is github.com/curl/ but I could be wrong (e.g. 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 "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

groks those URLs. curl has 19 repositories available. Follow their code on GitHub.

^GitHub

🇬🇧 Finally we're live with a new set of features! More than 18% of the apps at IzzyOnDroid already have Reproducible Builds – that's more than 1 out of 6, and more will follow. Two wonderful clients will make this and more transparent for you soon. Read about all the exciting news in this article: android.izzysoft.de/articles/n…

All this was made possible thanks to the help of @obfusk – and her github.com/obfusk/rbtlog

#IzzyOnDroid #reproducibleBuilds #FDroid #transparency

Reproducible Builds, special client support and more in our repo

Exciting news at the IzzyOnDroid repo! Now we have Reproducible Builds, specific support by some of the most popular F-Droid clients, and more!

^IzzyOnDroid