> Up to the trustworthiness of the CA system yes you can. If the author's site is serving malicious downloads to the curl UA then you're probably hosed either way. It would be easier to just slip malicious code in the software itself.
If they have HSTS, otherwise you might end up using plain ol' http by accident. Like over at surge.sh, but at least they use a package manager.
> Nobody who is running curl|bash isn't installing a 'random' binary but downloading an installer from a source they trust.
But you can't trust it, because most shell scripts out there are woefully inadequate. So you're one broken connection, one WiFi drop, from corrupting your system. At least a binary needs to be complete to run.
Example: Heroku's CLI [0]
If it breaks on the echo, you could end up overwriting your entire source list.
e.g. It breaks to:
echo "deb https://cli-assets.heroku.com/branches/stable/apt ./" > /etc/apt/sources.list
instead of the intended
echo "deb https://cli-assets.heroku.com/branches/stable/apt ./" > /etc/apt/sources.list.d/heroku.list
And it'll work too, because the entire thing runs as the root user.
> The argument surrounding curl|bash should really focus on this rather than hand-wavy security.
They're the same thing. A broken connection with curl | sh is a security problem. As is downgraded https, because of an accidentally misconfigured host. As is running without even the basic check of seeing if you get the complete file before executing it.
Everything about curl | sh is inherently untrustworthy.
[0] https://cli-assets.heroku.com/install-ubuntu.sh
