If you write software on Unix, you've probably seen this many times:
curl example.org/install.sh | sh
Often, there is a sudo
involved.
This is bad, for four main reasons:
It's (usually) insecure.
Far too many installation instructions use plain HTTP (or omit the URL scheme), which means that any malicious intermediary can inject arbitrary code and compromise the user's system. Well-known URLs means that attackers can passively target them on any network where developers might connect to the Internet (Wi-Fi hotspots, coffee shops, hackathons…)
It's dangerously unreliable.
Even if you use securely verified HTTPS for distribution, if the connection fails while in progress, the truncated script will still be executed. If you're lucky, this might only give you an error, or a broken installation. If you're unlucky, the consequences could be disastrous: for example, rm -rf /tmp/foo/...
could be truncated into rm -rf /
.
It's usually poorly targeted.
Even if you solve the previous two problems, these installation scripts usually target the host environment badly. They might mess with /usr/local
or /opt
instead of using your OS's package manager, or vice versa. They might install their own copies of dependencies, when you want them to use your existing ones, or vice versa. They might install stuff into ~/bin
when you want ~/.local/bin
, or vice versa. The script has to try and work on every common OS and configuration in a fool-proof fashion, which usually means not supporting any particular OS or configuration particularly well.
It obscures useful choices. Because these scripts are intended to be fire-and-forget, many choices of versions, options, and other tweakables are obscured.