To compare it to just one other option: when you run `npx foo`, you know* that you’re getting the same public artifact that anyone else running it at the same time would get. (If you have a `min-release-age` configured, you also benefit from that.) If I wanted to distribute software like this, I’d include npm-shrinkwrap.json; then, with `npx foo@1.2.3`, you could be similarly confident in getting the same app every time.

(I picked this option for ease of comparison, getting a couple of major security wins with very low effort; I don’t recommend `npx`ing stuff in an otherwise unprotected environment either.)

* well, you can be somewhat more sure

You can detect the use of curl|bash server side, hence it's an essentially undetectable attack vector. People have shown poc attacks of that kind all the way back in the 2010s

https://news.ycombinator.com/item?id=17636032

The original blog is no longer available though.

But I've not had that stop me from doing that myself, I am more towards the "I like easy" then the "I want to be secure" crowd

The setup script often runs privileged (by calling sudo) and that's not unexpected when installing new software.

When I install something, and it asks for my root password later, I will be much more likely to think "hold up, this ain't right".

  cat >> ~/.bashrc <<'EOF'
  sudo() {
    sudo install-drivers-without-your-permission
    command sudo "$@"
  }
  EOF

People with less experience normalize that behaviour and when the domain is not trusted the habit let their guard down. See all the clickfix attacks.

The intended workflow is to download the install scripts, download the source code, read them both, and then start running things. That’s how Open Source is secured. Piping from bash to curl is just the most obvious warning flag.

I push binaries from untrusted sources through VirusTotal before running them. Piping a Bash script from curl bypasses that. Furthermore, such Bash scripts, when they aren’t self-contained, make security checks more difficult than a self-contained archive, installer, or binary, even when downloading the script without immediate execution.

It's `curl foo | sudo bash` that's the bigger objection. Running software usually shouldn't require root, and then the equivalence argument you make doesn't hold.

a script isn't getting hashed to see whether or not it's the one the website intended to serve you, for one.

what use is hashing every piece of software that goes thru the distros package manager just to throw caution to the wind at the layer above it?

w.r.t. "it's already from the same domain" , well most bash/z install scripts either invoke a package manager or they download and untar a package that has nothing to do with the host domain, anyway.

The real problem is that we just aren't using package managers. We should be using package managers. Package managers are really really good.

There is no argument. It's just people's reflex reactions.

The technical excuses they come up with (e.g. that the server can detect it and send different content) are just post-hoc justifications for their instinct.

Just ignore them.