`curl https://[...] | sh` is not any more insecure than any other method of installing software. if you don't trust the person distributing that software to not try to own you through the install script, *why are you installing their software*
it's not like `tar xvf blah.tgz; ./configure; make; make install` is any more secure, unless you want to pretend like you're reading those configure and makefiles
the only valid concern is that it can cause shit to break if your connection closes in the middle of downloading the script (especially if it closes in the middle of a *line*), so you should always wrap the body of your script in a function and then invoke it at the end
or from a user perspective; download the script and then run it
@hierarchon literally true
@hierarchon the good curl | sh scripts wrap everything in a function, or just chainload into doing exactly this (e.g. rustup.sh downloads the appropriate rustup binary for your platform and then execs)
@hierarchon I remember that fun blog post where someone could detect if download is piped into shell or not and serve another script
@hierarchon eh, not sure this addresses the reasons why people consider this suboptimal practice:
1) they ask you to curl a script to a ROOT shell, not a user shell, which essentially provides privileged RCE
2) using a downstream distribution, you at least guarantee one independent person has audited the code and is vouching for it; more layers to catch bad actors
3) can't ensure binaries correspond to source. The devs might be trustworthy but binaries compromised, e.g. https://www.zdnet.com/article/backdoor-code-found-in-11-ruby-libraries/
1) anything that would pipe into a root shell would make you run `sudo make install`, and it's pretty easy to leverage non-root RCE in this context into root RCE by, say, modifying $PATH to put an evil sudo somewhere on the system
2) this isn't `curl | sh` vs 'install via your package manager', this is `curl | sh` via `configure; make; make install` (or `sudo make install`) which has the exact same security properties
3) this is the same binaries-vs-source issue and has nothing to do with curl vs 'download this binary and shove it in your $PATH'
@hierarchon 1) installing untrusted software in any context as root is bad, no arguments there
2) your toot says "is not any more insecure than *any* other method of installing software" (emphasis mine) so perhaps you were just exaggerating? :)
3) ...no? I'm a packager, the majority of these `curl ... | sh` scripts in my experience are shorthand to download a prebuilt binary, they rarely do local builds
2) yeah, I was exaggerating there. that, or with an implied "... assuming the software dev themself is not malicious or compromised".
3) sure, but for a lot of software I see "to install our software on debian, add our apt repository", and that would certainly have the same issue of prebuilt binaries.
@hierarchon it at least is *easier* for an opportunistic third-party attack, coffee shop WiFi/corrupt webhost sort of thing. "drop this snippet at the front of any request to *sh" is easier and more scalable than "parse the tarball, search for Makefile/CMakeLists/meson.build/configure.ac/package.json, add in a language-specific snippet and add it to the default target, recompress the tarball.." which would either need to be tailored to the specific package or would automate rather poorly
depends on the threat model. can't be safe from the maintainer, absolutely. can maybe pick a method that's not so trivial to subvert for a third party
@quarky yes, and that's why i specifically said *https*
@hierarchon that's fair
@hierarchon It's a lot worse than installing using a sandboxed package manager such as Flatpak or Snap. That rarely seems to be what people are complaining about though.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!