@space Yes, the problem is distros that continue using the "random third party mirror" model to distribute their installers/ISOs. Even if they consistently use HTTPS, it's much easier to compromise a random mirror since they are run by many third parties. Of course when they do this they invariably offer at least a SHA hash of the iso or something on the primary website, but most people don't check that.

Random third party mirrors are fine for automated install systems that verify signatures without user interaction (e.g. package repositories), but I consider it an antipattern in this day and age for direct user distribution because the vast majority of users that don't verify anything will be exposed to the attack surface of countless third parties. For Asahi we use a commercial CDN, so there is a single point of compromise (and if you hack into Bunny.net or Amazon there are probably juicier targets than us).

We could further improve this by making the bootstrap script a trust root that verifies everything else directly, and serving it from an even more tightly controlled server, though we don't do that today (yet).

@lkundrak I help maintain a bunch of Fedora packages and I don't even know how to set up sig verification for source files. Whatever I download on my workstation is what gets hashed and blessed as the real source.

But honestly, most projects these days don't even sign releases, they just host directly from GitHub tags or what have you. The assumption is that GitHub itself is secure enough and people know how to keep their repos secure (or if they get directly compromised, people will notice quickly). I do at least sign my tags on Git, but literally nobody checks that and I've had other contributors push release tags without a sig before and nobody cared.

Given the rather few stories of outright infra compromises leading to actual downstream compromise, and the most recent Jia Tan social engineering episode (which *gasp* even had tarball signatures, and in fact was *aided* by out-of-band tar releases not being directly sourced from GitHub!), I think we're doing okay on infra and we should be a lot more worried about social engineering and hidden backdoors than that.

(Oh yeah, and the part where the Intel employee responsible for maintaining a certain Linux driver deliberately introduced a security bug because he was lazy and admitted so in a comment and the commit message, and nobody cared, and I just found out 3 years later... yeah, we really have much bigger things to worry about than package signatures, seriously)

@chebra Funny enough today is the first time anyone has made a non invalid argument (that they're in the aforementioned 0.1%), hence this discussion and specific explanation of that case.

But no, I don't particularly care about how many people are wrong and use invalid arguments. There are lots of people who are wrong on the internet. Everyone I actually care about and trust agrees our usage of curl|sh is fine, as do the vast majority of our users who have no issue with it. That a small number of loud voices disagree doesn't make them right.

@zanagb The script has a basic truncation guard and proper error handling, so there's no real way for unintentional truncation/corruption to go undetected. The bulk of the installer is downloaded as a separate step (and if the download or unpack fails the script aborts). The top level curl part is just a very simple bootstrap.

Of course you can have things like your network die mid-install, but there isn't much we can do about that (the installer streams the actual OS install data directly to the destination, this is a good thing since it avoids having to leave aside staging space and works from recovery mode where no staging space may be available at all). We do have retries and such for intermittent errors, and also reduce the block size when errors happen to help out with flaky connections.

If something does fail and abort, well, manually doing the cleanup/uninstall steps and trying again isn't a huge deal. The actual steps to make the install bootable happen at the end, so it's not possible to end up with an "accidentally booting but actually subtly incomplete/corrupted" install (I think).

@christmastree https://social.treehouse.systems/@marcan/112490298461959027

TL;DR using a commercial CDN is more secure than piles of random third-party volunteer mirrors when you don't have an automated chain of trust system (like when you're just offering ISO downloads with a SHA hash that most users won't bother to verify).

curl|sh, by virtue of executing code, actually allows you/any distro to establish an automated chain of trust and not even have to trust the mirrors, though we don't do that yet ourselves since our attack surface is small since we use a CDN anyway. For distros that insist on the random mirror approach, *switching* to a curl|sh script served from the home page that chooses a mirror, then downloads the file and verifies it, would indeed increase their security.

@mppf If our web server gets hacked it could serve different images to different people regardless of the verification/delivery mechanism. The attacker just has to change the SHA hash or PGP key or whatever else security theatre approach you use to "verify" the file with data coming from a web server anyway.

The script is just a bootstrap. The actual installer gets downloaded and unpacked to /tmp. Yes a malicious script could do something non persistent directly in the bootstrap. But a malicious download could also self-modify to erase the malicious part after it's done. This is a red herring.

That is: none of your arguments are arguments against curl|sh that don't also apply to everything else.