[shakna]

> You didn't answer the 'random ip' question.

Just because you have a URL, doesn't mean it is connecting to the expected IP. Not everyone uses https yet. Not everyone uses HSTS to protect against downgrading.

> Assuming you take the same precautions you'd take with any other software download (like using https), there's no difference between curl-piped-to-sh and clicking on a link to a rpm, deb, exe, or anything else.

And that assumption isn't a guarantee. Remember who these kinds of installs target: developers with little experience. You can't ensure they'll notice a missing 's'. You can't ensure a worn-out admin will either.

> Not if the shell script is written correctly. And if you can't trust the source of your software to get that right, then you can't trust them to get the regular installers right either, so there's no difference here either.

No. I can't. Have a glance over Heroku's Ubuntu script.[0] It's not fenced, if that echo breaks, it could case some chaos. In fact, none of the commands are even checked for success, except the su.

> No one's advocating for random binaries, but you do have to install binaries from time to time, no? Or are you getting your CPU microcode updates in source form too?

If you look one level up, it's specifically binary installers. And secondly, I use a package manager, which has some review of this kind of thing.

I wouldn't curl a microcode update. That's asking for trouble.

[0] https://cli-assets.heroku.com/install-ubuntu.sh

[jjnoakes]

> Just because you have a URL, doesn't mean it is connecting to the expected IP.

Ignoring how weak of an argument that is, I don't see how that is any different of a risk between curl-pipe-to-sh and regular software downloads.

> Remember who these kinds of installs target: developers with little experience.

I think that's a little condescending. I image these kinds of installers target folks who want to get up and running quickly and conveniently, regardless of their experience. And I imagine, on average, folks pasting this into their shell have more than average experience already, since they (1) went out of their way to try this software and (2) know how to open a shell and copy commands into it.

> You can't ensure they'll notice a missing 's'. You can't ensure a worn-out admin will either.

You think it's more likely they will notice the missing 's' in the click-to-download-the-installer scenario than in the paste-a-command-into-the-shell scenario? I find that hard to believe.

> Have a glance over Heroku's Ubuntu script.[0] It's not fenced, if that echo breaks, it could case some chaos.

So file an issue. If their normal installer has bugs in it, things would break too. I don't see the difference. Buggy installers are buggy, which is just an argument against buggy installers, not against different install methods.

> I wouldn't curl a microcode update.

You missed the point. You can download it any way you like; unless you have its source, though, you can't audit it at all. So your claim that binary software is untrustable falls short in the practical world.

[shakna]

> So your claim that binary software is untrustable falls short in the practical world.

Where the hell do you think I made that claim?

> So file an issue.

Are you just trying to ignore everything I say? I responded to a claim that shell installers would be written correctly, with evidence that a fairly sizeable company doesn't get it right.

Your response to that is that it doesn't matter.

> You think it's more likely they will notice the missing 's' in the click-to-download-the-installer scenario than in the paste-a-command-into-the-shell scenario? I find that hard to believe.

A giant green bar is a little bit more than a single letter.

---

You really don't seem interested in a conversation about the shortcomings that exist. You seem interested only picking holes and saying that you are correct.

I have no interest in responding to that kind of conversation.

[jjnoakes]

> Where the hell do you think I made that claim?

Right here:

https://news.ycombinator.com/item?id=16144785

You said:

"Don't install random binaries either. The security implications of that should be fairly obvious."

> a fairly sizeable company doesn't get it right.

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.

> A giant green bar is a little bit more than a single letter.

Ah but you don't get the green bar for the file you are downloading, you only get it for the page that linked to it. So that's not good enough either.

> You really don't seem interested in a conversation about the shortcomings that exist.

You aren't raising many valid ones; it isn't my fault that the holes are so easy to find.

If you ease up on the hostile language and come back with some arguments that are a bit stronger, maybe you won't feel like this conversation is so one-sided.

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. I have no horse in the race, but cargo cult shunning of a popular install method isn't right. One ought to have real arguments which stand up to a little scrutiny.

[shakna]

> 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.

[jjnoakes]

> I also said to use a package manager.

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.

[shakna]

So... You disagree that I'm allowed to say what I say, because apparently in your world it means something different...

And you consider everything else irrelevant because you want it to be.

You're not interested in a discussion.