Package managers are outside the scope of this discussion though. I agree they are great when they can be used, but for various reasons they can't be used (no root access, the software or the version or the configuration or the architecture one wants isn't available, etc).
This discussion really is about the relative differences in security between curl-piped-to-sh and downloading software some other manual way (opaque installer, tarball full of source, etc).
> Claiming I've said binaries are inherently unsafe could not be further from the truth
I'm not so sure. One of your arguments against curl-piped-to-sh is that it's hard to audit (which I disagree with in general, but that's irrelevant for this point), but if that really was a concern for you, then I don't think it's unreasonable to infer that anything hard to audit would be just as objectionable, like binaries in various forms (and therefore this argument wouldn't apply only to curl-piped-to-sh).
> They've also had SSL downgrading issues in the past, allowing MITM attacks trivially
Which applies to more than curl-piped-to-sh, so this is irrelevant here. This is an argument against Heroku, not against this installation method.
> 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.
The quality of the installation method is not a function of the method itself, but a function of its popularity. If you are arguing that less popular installation methods may have more bugs, then I agree with you, but to then argue that curl-piped-to-sh is therefore inherently buggier than installers or packages doesn't follow. I'd bet if a company's most popular installation method was curl-piped-to-sh and there was some problem with it that affected their users, they'd fix it just as quickly.
So this isn't specific to curl-piped-to-sh, and is irrelevant.
> There are exactly four problems I have with curl | sh.
> SSL downgrading
Not specific to curl-piped-to-sh. Irrelevant.
> You can't mitigate curl | sh trustworthiness by checking in your browser
Not specific to curl-piped-to-sh. Irrelevant.
> Root
Not specific to curl-piped-to-sh. Irrelevant.
> Partial file execution / only shell can break a system when the file is incomplete
This is the only actual argument related to the difference between the two, and it's one we've already hashed through a few times. I agree it's a difference, but I disagree it's a major flaw, cause for concern, or a reason to abandon the curl method.
