It's not really any different than downloading a binary from a website, which we've been doing for 30 years. Ultimately, it all comes down to trusting the source.
>> Attacks like this are not helped by the increasingly-common "curl | bash" installation instructions ...
> It's not really any different than downloading a binary from a website, which we've been doing for 30 years.
The two are very different, even though some ecosystems (such as PHP) have used the "curl | bash" idiom for about the same amount of time. Specifically, binary downloads from reputable sites have separately published hashes (MD5, SHA, etc.) to confirm what is being retrieved along with other mechanisms to certify the source of the binaries.
Which is the reason why it's better to actually cryptographically sign the packages, and put a key in some trusted keystore, where it can actually be verified to belong to the real distributor, as well as proving that the key hasn't been changed in X amount of days/months/years.
Still doesn't address the fact that keys can be stolen, people can be tricked, and the gigantic all-consuming issue of people just being too lazy to go through with verifying anything in the first place. (Which is sadly not really a thing you can blame people for, it takes up time for no easily directly discernable reason other than the vague feeling of security, and I myself have done it many more times than I would like to admit...)
> If the attacker already controls the download link and has a valid https certificate, can't they just modify the published hash as well?
This implies an attacker controlling the server having the certificate's private key or the certificate's private key otherwise being exfiltrated (likely in conjunction with a DNS poisoning attack). There is no way for a network client to defend against this type of TLS[0] compromise.
Which is why package managers with well-maintained repositories are the civilized solution to software disruption. Unfortunately the Linux world has been dedicating a lot of energy to making Windows-style "download and run the exe" possible on Linux.
>Which is why package managers with well-maintained repositories are the civilized solution to software disruption.
How does that model work with distros like debian, where they freeze package versions and you might not get claude code until 2027 (or whenever the next release is)?
>Sounds like you either shouldn't use Debian or should find a repo with maintainers who align with your preferred style of package inclusion.
Are there actually viable alternatives to the default debian repo? At best there's repositories run by various projects, but that's basically the same as level of security as "run a random binary you downloaded off the internet". The only plausible way that package managers increase security is through curation. If you're just blindly adding whatever repo to get some software installed, you're back at square one.
If the debian maintainers don't align with your preferences you can:
1. Create your own apt repository with newer software, and install from that. It's easy to package things, you can share the repository with trusted friends, running linux with friends is fun.
2. You can switch to a distro, like NixOS or Arch, which values up-to-date software more than slow stable updates.
Debian does seem to be more aligned with mailservers and such, where updates can be slow and thoughtful, not as much with personal ai development boxes where you want the hot new ai tool of the week available asap.
... Either way, learning to package software correctly for your distro of choice is a good idea, it's fun to bang out a nix expression or debian package when you need to install something that's not available yet.
I've heard this time and time again from new Linux users: "I don't want to learn the command line, I just want to be able to install and run whatever I want"
On Mac binaries need to be signed and notarized and Apple could stop the spread of the malware once it's identified or even detect it before notarizing it.
I've downloaded and installed too many packages where the developers didn't bother with this, but I uncritically went to Mac's security settings to let it do its thing anyway.
I don't know if developer utilities can be distributed through the app store, but they should be so that Apple can review them properly. Criticisms aside, the iOS App Store and the iOS security model has been the best thing for software security (especially for lay-people), ever.
Apple controlling CLI utilities is a bad supposedly good idea.
They can’t stop themselves from tightening their grip ever tighter, and always want to ensure you have no functionality above what they deemed sufficient.
