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