Skip to main content

Can I just say that I have created #curl releases "the #xz way" since the 90s: I generate the release tarballs on my machine. It makes the tarball have (generated) files included that are not present in git. It's a feature. But it also makes it harder for observers to figure out if the additional files are fine or not.
#xz #curl
in reply to daniel:// stenberg://

BenBE
BenBE
• •

Any chance for curl releases to be generated with a CI/CD process, where the exact commands are documented publicly AND are run on a system that's NOT your usual development system?

Example: htop:
https://github.com/htop-dev/htop/blob/main/.github/workflows/build_release.yml


htop/.github/workflows/build_release.yml at main · htop-dev/htop

htop - an interactive process viewer. Contribute to htop-dev/htop development by creating an account on GitHub.
GitHub
in reply to BenBE

daniel:// stenberg://
daniel:// stenberg://
• •
@benbe Maybe. I won't rule it out, but to me its a question of efforts and what we get in return. I'm sure lots of people will now ask (or tell) me to. But no one will help me or fund me do it.
@BenBE
in reply to daniel:// stenberg://

scy
scy
• •
I really hope that one of the outcomes of this will be a huge push towards reproducible builds, and that this will improve workflows and tooling and defaults and make it easier.
This entry was edited (1 month ago)
in reply to scy

daniel:// stenberg://
daniel:// stenberg://
• •
@scy @benbe you then assume that people would actually verify and check the tarballs. Which I bet not many people do or will. At least in the past. Maybe things will be different going forward...
@scy @BenBE
in reply to daniel:// stenberg://

BenBE
BenBE
• •
@scy I think if you can build the tarballs from publically available instructions reproducibly, you don't need to verify yourself, but there will likely enough people having an eye on the situation. Interesting times ahead …
@scy
in reply to daniel:// stenberg://

Heath Stewart
Heath Stewart
• •

@scy @benbe This. There's currently no proof that the release came from the CI. Maybe the CI did publish something, but how do you know it wasn't replaced by a compromised maintainer?

There could be solutions, though: print the hash on the CI (people would so have to check it), have hosted agents sign e.g., gpg, releases like GitHub does for commits it makes and show a green check for such artifacts. Still, users would have to verify the build scripts weren't compromised. Who'd do that?

@scy @BenBE
in reply to daniel:// stenberg://

Brian Campbell
Brian Campbell
• •

@scy @benbe A lot of distros have been working on build reproducibility issues, and additionally sometimes basing sources on git rather than tarballs.

It's not going to help in all cases, but it's possible that one of the build reproducibility projects could have caught this.

@scy @BenBE
in reply to daniel:// stenberg://

Pink
Pink
• •
@scy @benbe I’m honestly amazed that such little incidents happen in the great scheme of things. There is so much trust involved in computing. You’re always relying on thousands of people not screwing up their part of the abstraction layer, and you can’t possibly verify or even understand everything. It’s all built on trust, no matter how much we want to believe that this isn’t the case.
@scy @BenBE
in reply to daniel:// stenberg://

Christen Lofland
Christen Lofland
• •
@benbe Yeah, this is the issue. We can make up new rules and requirements, but the organizations that make enough money to pay their executives millions of dollars every year by relying on your code won’t spend any money on this, other than perhaps to hire some auditors to yell at you.
@BenBE
in reply to daniel:// stenberg://

Patric Mueller
Patric Mueller
• •
And are you going to change something about that now?
Commiting generated files to git is the easy fix.
Another option is to generate the release tarballs on a public CI that is likely harder to breach?
in reply to daniel:// stenberg://

Tom
Tom
• •
Also, a compromise of your machine may compromise the tarball. But if that tarball is 100% reproducible, that could be detected.
in reply to daniel:// stenberg://

guenther
guenther
• •
so either you're trustworthy or you're just playing a reeeeeeally long game here ^^
in reply to daniel:// stenberg://

Brian Campbell
Brian Campbell
• •

Yeah, it's a common pattern, that's why it worked so well.

I think it would be better for those kinds of steps to be done by a reproducible build that could happen in CI, and that package maintainers could do themselves to verify that it's reproducible, but this got by so easily in part because it's such a common pattern.

in reply to daniel:// stenberg://

cesarb
cesarb
• •
It might be enough to just say for instance "this tarball was generated from commit nnnnnnnn on Debian stable up-to-date as of xxxx-xx-xx using autoconf yy.y" (and generating it from a clean checkout). Someone who wants to verify can download the packages as of that date and that autoconf version, run the script to generate the tarball, and compare; the resulting diff should be small enough to audit quickly by hand. That should be low enough effort for both you and the verifier.
in reply to cesarb

daniel:// stenberg://
daniel:// stenberg://
• •
@cesarb true. And basically we already do that. The release is based on a known public (signed) tag and the version number of the involved tools are visible as well.
@cesarb
in reply to daniel:// stenberg://

cesarb
cesarb
• •
I tried it just for fun, got curl 8.7.1 from the github release page, unpacked within a docker.io/library/debian image in podman, installed "autoconf automake libtool make libssl-dev libz-dev", ran "autoreconf -fi" and "./configure --with-openssl" and "make dist", and other than missing CHANGES and vcxproj files, the resulting diff from curl 8.7.1 from curl.haxx.se was small enough to review by hand in just a few minutes. It should probably be easy to get an even smaller diff.
in reply to daniel:// stenberg://

cesarb
cesarb
• •
Just tried it again, this time with docker.io/library/ubuntu:23.10 as the image, and the result was even closer (only difference besides version numbers in generated files was --gnu versus --foreign for some reason, and CHANGES and vcxproj files are still missing).
⇧