I still have no comprehension of how curl piped into a shell command has become the default installation method for many projects (looking at you, Rust...). It breaks my brain as to how potentially unsafe it is.
The correct way is to have M of N signatures on specific package manager pinned versions. And you trust the auditors to look at each new version, of a well-known package.
We should start a project and get it funded, to do just that. The money can go to LLM tokens for audits, at least, and hosting the multisigs and the package managers.
Anyone want to partner on this? See my profile on HN and email me.
Curl piped into a shell command provides no means to verify that the download is uncorrupted and unmodified before running it. For example, whenever I download software manually I check the downloaded file against the verified checksums to ensure that I have an unmodified version. Ideally I check this with gpg --verify on the signed checksum file (against the source's public key). This is a standard procedure for many organizations [1]. If you just download something and immediately run it without this step, you could potentially run a hacked version of the installation script.
SSL/TLS/HTTPS is more about encrypting the traffic and ensuring that there was no tampering with the file between you and the server. The steps that I describe are more about ensuring that there was no tampering between you and the original source. Those are two separate problems. If you just rely on HTTPS, somebody can replace the file on the server with a modified version, and you would not know.
It is also possible to have a signed file that you can use to check the authenticity of a downloaded file directly without having to use checksums. Rust [1] does it that way for its other installation methods.
[1] https://forge.rust-lang.org/infra/other-installation-methods...
But this is new software from someone no one trusts yet. Verifying the binary was not maliciously replaced by someone else doesn’t matter.
What we need here is a reproducible build made and published by an independent third-party.
Having a binary also allows for antivirus software to be ran on it before deciding to run the binary itself or not.
I am not sure if curl | sh bypass sandboxing by default, but definitely is the case when compared to flatpak or just regular packaging
An evil person could present a normal install script for other browsers and randomly present a malicious one for curl clients.
At least with the downloaded file, that is the thing you get.
By comparison, a curl|bash not only skips over my ability to do any of that but it also introduces two new potential paths to exploitation if a malicious user has control over the web server. There's the classic "hidden text that doesn't appear visually but will be in the copy/paste version" and the more complicated "server detection of manual download vs. curl|bash to deliver different content".
A curl|bash saves the "friction" of a `chmod +x` command and maybe an unzip/untar in exchange for introducing multiple different ways for malicious actions to be hidden.
Would you feel safer if they offered a .deb? Do you unpack and inspect every .deb you install?
A .deb file has many advantages over curl piped into a shell. You can check the contents before installation, you can potentially verify the authenticity of the .deb file, and dpkg makes it possible to uninstall the package later since it keeps track of what it installed in an organized manner.
I won't say that I would feel safer with a .deb file. That depends on the source, what the package does, and other factors. Security is about tradeoffs. I personally find the tradeoffs associated with a .deb file better than the tradeoffs of curl piped into a shell, but I myself do not install .deb files in the first place since I get almost everything that I need from package repositories.
What we are really missing is an explicit progression from new software to maintained packages across distribution. As it is, each distro expects each package to have a maintainer, and very few people actually want to do that across several distros just to release their software. Generally, the expectation is to instead just wait around for people to make and maintain those packages by virtue of their own interest in your software, but it takes a while, and discoverability isn't automatic.
Depending on third party packaging (distribution-validated install) is much higher friction.