[whywhywhywhy]

Having an install script that you paste into the terminal and all it does is download a binary and stick it in a folder is wild.

If your users are savvy enough to be running random scripts they shouldn't need a script to do this and if they're not savvy enough to understand how to do that then the last thing they should be doing on earth is running a random terminal command off a website.

[atrettel]

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.

[barnabee]

Everyone’s eventually going to run a binary they downloaded from the same place, if you’ve already decided to do that, why is a curled install script worse?

[yubblegum]

Because it normalizes a practice that, while acceptable in context of a well known project with numerous dedicated eyeballs such as Rust language, is not a generally acceptable method of installing software.

[EGreg]

Exactly this.

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.

[blourvim]

The web server is able to detect and change the response of a curl | sh thus a malicious actor could avoid some detection.

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

[wolrah]

Because if I download a binary package I can then fully inspect it before installation and be sure it's actually what I intended to install. If it's actually a package for my chosen variety of package manager it's probably signed too. Even if we're talking about just a single static binary distributed by the developer where I don't have the skills to usefully analyze it, the fact that I can verify that the binary I downloaded is the same as the binary everyone else using it on my platform has been using for however long without issue that still offers some level of trust.

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.

[atrettel]

The issue does not have to do with whether the download is a binary or source code. It has to deal with verifying the integrity of the download before installation.

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.

[1] https://www.debian.org/CD/verify

[NAR8789]

Doesn't curl still validate ssl certificates? So long as I'm curling an https url from a trusted domain, don't I still have a chain of trust?

[atrettel]

Curl does verify certificates [1]. That does confirm that your connection is to the right server, but it does not confirm that the files were unmodified.

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.

[1] https://curl.se/docs/sslcerts.html

[nazcan]

But where do you get the checksum from? I realize in some cases you are downloading from a mirror (thus as long as you trust the source of the checksum, that is quite useful) - but if it is from the same host - then you are just comparing against the same webserver.

[drdexebtjl]

For a Debian image, yeah, that is the threat.

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.

[BobbyTables2]

A webserver could alter the payload based on the client.

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.

[petcat]

Every package manager does the same thing: run a script.

Would you feel safer if they offered a .deb? Do you unpack and inspect every .deb you install?

[atrettel]

I get what you are saying, but my issue is not that it runs a script. My issue is that curl piped into a shell does not verify that the download is from the original source before running the script.

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.

[thomastjeffery]

It's because people are too obsessed with providing complete instructions to incorporate any package manager into their instructions.

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.

[da-x]

It's all about lowest friction + domain-name trust.

Depending on third party packaging (distribution-validated install) is much higher friction.

[TZubiri]

Those that ask for trust, deserve no trust.

[asdsd34sdfsdf]

Look, you are going to run an executable. There is no way around it. At some point you are going to fork over inscrutable, opaque sets of bits to your CPU and loudly proclaim them to be executable. The CPU does not know, cannot know and does not care. At some point this will be done. No matter how many hashes, digests and public keys you verify, the bits will be interpreted as instructions and energy will be expended to explore a state space you were told is or leads to the promised land. If deception is involved in any step in this process, the end result will not be what you expect it to be. The peculiarities of the transport mechanism by which these bits were transported to your particular device of computation is very nearly the absolute least interesting thing to worry about in this whole shit-show.

It's completely insane our desktop OSes are holding highly private data like banking details with zero meaningful support for sand-boxing.

This whole problem would be a non-issue if we got proper auditing and management tools. If we could properly inspect our system's resources and see what sandbox has access to what and when and how and at what time, etc. I could draw a line around a "file" or "directory" and proclaim it to be off-limits to everything but "banking app" or whatever.

All the signature verification in the world won't protect my sensitive data from being raw-dogged by this Verified(TM) binary blob. I understand it solves a different problem, but to me all this "proper package management" is theater if the other side of the equation is not being handled with the same amount of attention.

[keepupnow]

You can create secure inaccessible directories for files via Cryptomator or Veracrypt or similar. It should be encouraged more IMO.

[ElectricalUnion]

If your files and folders are rw even in a encrypted form, you're still vulnerable to ramsomware if you don't have some sort of immutable ro backups.

[anon7000]

Yeah, if the script only downloads something from GH releases and doesn’t even put it in a bin dir… why not just make it a normal download from the website

[brookst]

Because the script can do branching logic and checks that you otherwise have to explain to the user.

Not defending the practice, I don’t like it. But the intent is to make it easier.

[jayd16]

What would be your preferred solution?

[whywhywhywhy]

Said in the post, if they're savvy enough to inspect an install script they can click and download a binary for their OS, chmod +x and move to whatever bin they want.

Although really something like this you unproven you should compile it.

[dfish]

you can also do `cargo install rayfish`. But not everybody has cargo, etc etc etc

[zuzululu]

so how did you install npm or docker?

[mcsniff]

Using a package manager usually

[blackqueeriroh]

How did you install that package manager?

[whywhywhywhy]

Until recently it was the one single time in my entire computers livespan I would paste the curl command into the terminal then everything else would be through package manager.

Now thanks to claude code etc it's been normalized that everyones doing it and normies who shouldn't be doing it are getting used to doing it.

[singpolyma3]

It's part of the OS

[RadiozRadioz]

I didn't, it came with the system