Hacker News Reader

Comment by ivix | Hacker News Reader

Why would you say that is industry practice when it is not?

It's the suggested install for homebrew. http://mxcl.github.io/homebrew/

There are legit criticisms against the copy-paste-curl-command style of installations. But on the other hand, I've yet to see a critic proposing a viable alternative. With viable I mean that said proposal must:

1. Work on all major platforms.

2. Be easy for the developer to create.

3. Be easy for the user to execute, with as few steps as possible.

There are those who advocate that the developer should create a platform-specific package for every platform. While this fits their purist views in which only their own platform matters, this is not a good solution for the developer, who often has users from multiple platforms. Creating platform-specific packages places an unbelievable maintenance burden on the developer.

This is not to mention that platform-specific packages, too, have their own security flaws.

The most viable alternative is "apt-get" which provides simple downloads from a central package repository with signature checking. I believe pip and cpan are comparable. In this case I'm picking on homebrew, and the quoted curl command is the command to install that very package tool. The brew package manager does some lightweight checksum verification on subsequent downloads.

And apt-get directly violates point 1, "must work on all major platforms". APT is not widely used on e.g. OS X, Red Hat derivates, etc.

I look forward to you boiling the ocean. (Sadly, the only reason I know about this Homebrew stuff at all is that the APT-based Fink, for MacOS, is not very popular.)

The only difference between "wget | sh" and "download and run our installer" is that you could inspect the installer before running it. You can still do that, "wget | sh" just simplifies the process for most users.

You can also inspect the wgetted/curl'ed script if you so choose. It's just a URL. I don't understand your point.

Even with the "exploit" in the article, it will be detected as soon as the user pastes the URL in his browser location bar. People who don't inspect what they run are screwed no matter what.

The point, especially in a non-SSL environment, is not that you're not trusting Opscode or Homebrew. It's that a malicious attacker has a vector, because he knows people will be doing something with that URL.

If I own Opscode and I'm smart, I plant something like this on that URL:

    if request.user_agent.startswith("Curl or wget or..."):
        return deliver_malicious_script(request)
    return deliver_everything_is_fine_script(request)

Nearly everybody's workflow for "checking" this is putting the URL in your bar, looking at it, then jumping over to terminal and running it. (Sounds suspiciously like what you just described.) I just owned that with three lines of effort.

We can do this dance all day where people point out specifics, or we can all just recognize it's a bad idea (a lot of people are saying it's a bad idea; might be worth considering it's a bad idea).

I like very much the "copy-paste-curl-command style of installations" because it is as simple as possible, and it invites to be more creative during installation. I do not envisage to perform a copy-paste-curl-command installation, except perhaps in a not throw away VM. I generally perform the curl toward a temporary file, read the file and if it does look suspicious, I do not run it.

Reply on news.ycombinator.com