I'm not a fan of the "Reproducible tarballs" section, because it's explicitly about pre-processing the source code with autotools, instead of distributing a pure, unaltered git snapshot (which `git archive` can already generate in a deterministic way).<p>The section following then mentions signing the pre-processed source code, which I think is the wrong approach. It makes a difficult situation because of how strongly some people encourage signed source code, yet I think autotools is part of the build process and should run on the build server (and double checked by reproducible builds). If people pre-process the .orig.tar.xz they upload to Debian, this pre-processing won't be covered by reproducible builds because it happens undocumented.<p>The patch for "reproducible tarballs" is quite involved[0] and has rookie mistakes like "pin a specific container image using `@sha256:...` syntax, but then invoke `apt-get update` and `apt-get install` to install whatever Debian ships at that time".<p>[0]: <a href="https://github.com/curl/curl/pull/13250/files">https://github.com/curl/curl/pull/13250/files</a>
> We do not provide checksums for the tarballs simply because providing checksums next to the downloads adds almost no extra verification. If someone can tamper with the tarballs, they can probably update the webpage which a fake checksum as well.<p>In the past, I have occasionally downloaded a tarball from one mirror, and verified against a checksum from a different mirror (or from the official website). Back when release announcements were primarily made on mailing lists, using a mailing list archive to get a copy of the "real" checksum was also a possibility.<p>I definitely remember being advised to get the checksum from a different source than the tarball, a number of different times.<p>> Our policy says that if a contrition is good:<p>* contribution
I don't understand his attitude towards "anonymous maintainers". Right now ALL contributions to curl are pseudonymous, including his own. There is just no such organization as "Curl". Want to see non-anonymous contributors - go to Google/Intel/etc, they ask for IDs when they hire employees.<p><pre><code> > A (to me) surprisingly large amount of contributions are done by people who do not state a full real name
</code></pre>
Again, strange attitude, given that he personally had legal issues with US in the past, the reasons for which were never disclosed[1].<p>Typical good developers are not Rambo. When law enforcers come to them and force them at gunpoint to make them commit/add a new maintainer, they should not expect active resistance. Minor reminder: curl is not just some http library, they maintain their own CA list[2]. They don't need any intricate hidden lines for backdoor, CA list is a backdoor on its own.<p>[1] <a href="https://daniel.haxx.se/us-visa.html" rel="nofollow">https://daniel.haxx.se/us-visa.html</a><p>[2] <a href="https://curl.se/docs/caextract.html" rel="nofollow">https://curl.se/docs/caextract.html</a>
In Stagex we already produce a deterministic, full-source-bootstrapped, and oci-native builds of curl.<p>release: <a href="https://hub.docker.com/layers/stagex/curl/latest/images/sha256-dcb686988d8fc52abe879e4a6fb292b2f96103a2f9eedfb83509e3f965a85498?context=explore" rel="nofollow">https://hub.docker.com/layers/stagex/curl/latest/images/sha2...</a><p>source: <a href="https://codeberg.org/stagex/stagex/src/branch/main/packages/curl/Containerfile" rel="nofollow">https://codeberg.org/stagex/stagex/src/branch/main/packages/...</a><p>signatures: <a href="https://codeberg.org/stagex/stagex/src/branch/main/signatures/stagex/curl@sha256=dcb686988d8fc52abe879e4a6fb292b2f96103a2f9eedfb83509e3f965a85498" rel="nofollow">https://codeberg.org/stagex/stagex/src/branch/main/signature...</a><p>Every package is bootstrapped all the way up from a heavily reproduced 256 byte assembly seed (Stage0/live-bootstrap) and built by two or more maintainers with confirmed matching hashes, and with signatures from well known keys.<p>100% of commits in our repos are also signed, and every PR merge also comes with a signed merge commit by the reviewer.<p>Information on how to verify our keys is found in the maintainers file: <a href="https://codeberg.org/stagex/stagex/src/branch/main/MAINTAINERS" rel="nofollow">https://codeberg.org/stagex/stagex/src/branch/main/MAINTAINE...</a><p>If the curl team wants a similar level of supply chain security for their own official binaries or Dockerfile we would suggest cloning our Containerfile and hash-locking all dependencies to the latest stagex release (please by all means reproduce, verify, and sign that too!).<p>This should be easy for curl maintainers to build and get identical hashes for their own release binaries to the ones we build and sign.<p>Stagex could also be used to produce source tarballs with generated files from similarly deterministic/multi-signed versions of autotools etc.<p>I am not convinced there is a good case for having any auto-generated files in the source archives though. Force distros to bring their own autotools, etc., imo.
All of this is nice but none of it stops the style of hack that happened to xz besides the fact that it's very unlikely Dan is going to be bullied into handing over maintainership to someone else.<p>Every other element on the list can be attacked if the maintainer themselves is the malicious party carrying out the attack and it is being performed with the level of sophistication in the xz attack.<p>So ya, I'm not saying it's security theater in all contexts, but if the context is the attack vector used in the xz attack, it's security theater.
> A (to me) surprisingly large amount of contributions are done by people who do not state a full real name.<p>Why would someone state their full real name on the internet to contribute to curl? If someone wants to boost their CV, they can just write "curl, Linux kernel, GCC contributor" and provide the link to my GitHub profile upon request. Yes, someone in HR will (gasp) learn that orthoxerox is actually called Boris Kozlov in meatspace, but there's no need to broadcast this information.
I went as far as building code in PRs and reusing those blobs when the code gets merged in into main. I find it super weird that in many projects the code gets rebuild and packaged on merge to main, and when released, all while a lot of underlying processes aren't locked.<p><pre><code> apt install xyz
</code></pre>
can be different.<p>a python requirements.txt as well. (which is why we use Poetry).
C build systems are so cursed. Autotools is obviously horrible, but projects like curl cling to it, because somehow every other C build system sucks too.<p>It's frankly amazing how deeply fragmented and backwards-looking C is that this continues to be a problem. In the last 30 years, a countless number of C build systems have been created, and yet an ugly pile of obscure macros outlives them all.