A bit dramatic here, are we?

The script is safe regarding interrupted transfer, unless you happen to have a dangerous commands in your system matching ^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?).

And after that's been handled, well, what's the difference to just providing the script but not the command to invoke it? Surely if one wants to review it, downloading the script to be run separately is quite straightforward. (Though I there was a method for detecting piped scripts versus downloaded ones, but I don't think it works for such small scripts.)

Here you go [0] - the project hasn't launched yet and there are bits and pieces to be dealt with, the current focus is a bit somewhere else. You can also build from source [1] with Rust's cargo.

[0] https://files.radicle.xyz/latest/

[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...

Thanks but... no thanks, you've missed my point entirely. Why would I want to run peer to peer software built by developers whose security stance starts with curl-bash? Would you curl-bash a webserver? an email server? No? Probably even worse for your source code repository then right?

The problems with curl-bash are overblown. You are pretty much exactly as vulnerable running pip install, npm install, or cargo install.

Not that curl bash is great, but it's not uniquely horrible when the goal is to run some unvetted code on your machine.

If you care about security, you have to either vet the code or trust the source. When you install through your package manager, you're trusting the maintainers. When you install from curl bash, a random website, or any unvetted software source, you are electing to trust the developers or site directly.

Packages on those systems do get blocked at times. So no, not as risky.

The big difference with curl|bash is that the download itself gets to execute in the context of the computer as it is downloading, which is a super power that makes it much easier to hide behaviors as you can make it extremely difficult for people to ever be able to just download a dead copy of the script to analyze it for malware.

The counterpoint would be: you're intending to run their code, if it's malicious then you're hosed anyway.

In bygone times, one might suffer from a truncation attack or otherwise end up running arbitrary code that's not what the vendor intended. Nowadays, there's really no security difference in curl|bash vs downloading a package and running it. Or, indeed, installing using `cargo install`.

That doesn't mean I'm happy running it, but my argument against it is less a security argument and more a predictability one: I want to be able to cleanly uninstall later, and package managers normally provide more consistent support for uninstalling than an arbitrary shell script.

The cleanup and uninstall concern is one of the reasons I run as many things in containers as I can. It's so easy to blow away a container and its volumes compared to traditional software uninstallation.

Yeah, it’s much better to npx something or install a package off the AUR. Definitely much safer.

This is an overreaction, almost to the point of absurdity.

Risks inherent to pipe installers are well understood by many. Using your logic, we should abandon Homebrew [1] (>38k stars on GitHub), PiHole [2] (>46k stars on GitHub), Chef [3], RVM [4], and countless other open source projects that use one-step automated installers (by piping to bash).

A more reasonable response would be to coordinate with the developers to update the docs to provide alternative installation methods (or better detail risks), rather than throwing the baby out with the bathwater.

[1] https://brew.sh/

[2] https://github.com/pi-hole/pi-hole

[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...

[4] https://rvm.io/rvm/install

FWIW, Homebrew (no longer) deserves quite such ire as you will note that it explicitly does NOT pipe the result to a copy of bash: by downloading it first it and quoting it using a subshell it prevents the web server from being able to get interactive access.

Download it or don't. Trust the maintainer or don't. Whether you trust the maintainer or not shouldn't be a matter of the installation method, not even with curl-bash.