> I am truly interested in some serious arguments against piping to shell
Then here goes one last shot.
---
> You said:
> "Don't install random binaries either. The security implications of that should be fairly obvious."
I also said to use a package manager. So far as I'm aware, most package managers install binaries. I'm not an advocate against binaries.
In fact, I've said they're safer than curl | sh, because they don't execute when they're incomplete.
Package mangers also check binaries to see if they're not only intact, but have a level of correctness to them.
Claiming I've said binaries are inherently unsafe could not be further from the truth.
---
> Fairly sizable companies mess up a lot of things. That still isn't a good argument against piping to shell though, since it isn't exclusive to that method.
It is a good argument against shell, because only shell can break a system when the file is incomplete, because other methods of streaming executables are nearly non-existent.
And though you can protect against this, nobody has. If a frequently installed tool has the problem, then it is a problem, and can't just be ignored by saying that you can do it better.
Heroku have actually had the issue reported in the past, by myself as well as others. They've ignored it, because they don't think it's worth the effort.
They've also had SSL downgrading issues in the past, allowing MITM attacks trivially.
Docker has actually taken efforts to isolate their get script from this, but again, they aren't sure that they've actually plugged that hole.
If a company screws up their shell script, there's usually no recourse unless they're interested in listening to you.
If a company screws up their package, then they're required to act on it, or potentially have their package made inaccessible.
---
> I am truly interested in some serious arguments against piping to shell, if there are any besides the one I raised, since all I hear are these bogus ones any time this topic comes up.
There are exactly four problems I have with curl | sh.
* SSL downgrading. Every major organisation has faced it, and if curl | sh is your normal method, then there is probably a bot network waiting to step in and ruin a user's day. Most binary installers can be checked to see if they're broken, which mitigates most of the cloud of bots out there, because they don't tend to be sophisticated.
* Partial file execution. This is unique to the curl installer method, and can cause all sorts of havoc, and has. I've fixed systems that have had directories removed, and system files overwritten, and had $PATH destroyed.
* You can't mitigate curl | sh trustworthiness by checking in your browser. What you see and what you see can, and has, been different. I've seen browser downloads giving the latest stable, and curl giving the latest on git, which hasn't always been stable.
* Root. A lot of scripts will demand root at the start, so you don't get continually prompted. Unfortunately, this means they have the power of root when something like partial file execution leaves you with a line like: rm -rf $TMP, instead of rm -rf $TMP_DIR.
---
Piping to shell is unique in allowing partial execution, and can wreck havoc on a system.
Allowing a package manager to use the experience of several decades to prevent edge-cases when things go bad, is best. (And submitting to most package managers isn't an ordeal, and generally involves crafting a file with less than thirty simple lines in it.)
Downloading an installer is less preferable, but not vulnerable to partial execution, and most installer frameworks that get used also do some checksumming, which is again better than nothing.
The problem with curl | sh is simple: it is easier to do the wrong thing, than the right thing.
