Hacker News Reader

Comment by mellamoyo | Hacker News Reader

> curl -s http://getmacapps.com/raw/6bl | sh

> ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

Please stop doing this. I looked at the script and I know it looks fine but piping a raw curl into a shell interpreter is just a bad practice. Unfortunately, it seems to be more and more common as time goes on.

View on HN

I feel like this discussion comes up every time someone mentions homebrew. The conclusion I've come to is that `curl -s foo.com/bar | sh` is less secure than downloading and running an install script locally iff you intend to review the install script yourself.

If you're just downloading homebrew and running an install script by hand without reading it (as, honestly, I usually do), there's no difference.

It's also at least as safe as downloading and running a binary executable.

I see this assertion all the time, and I disagree.

For one thing, the script is coming over http, so it's trivial to intercept and replace the content, perhaps even silently so you get the original content plus a few extra box owning goodies. Two, as a .sh script, its self-selecting in terms of what system the binary executable has to be written for. Also, it's typically not as easy to escalate privileges in an executable as it is in an arbitrary shells script.

curl -s foo.com/bar | sh

curl -o install foo.com/bar && chmod a+x install && ./install

The script is an open source installer, the binary is hidden/closed. You and others at least have the option to inspect it.

The binary would also be coming over http (https is clearly preferred for binaries or scripts). A binary can always embed a script and do a 'system' call to execute any script-available privilege escalation.

I'm not sure what you mean by "as a .sh script, its self-selecting in terms of what system the binary executable has to be written for". I think you mean that a single .sh script can target multiple platforms. That doesn't mean a binary is any safer for you to download and execute on your system.

I agree with this 100%.

And here's to all replies that say it's as secure as a package: it's only partly about security.

The other part is version control. I can install a specific version of an RPM relatively easily, but wget|sh approach makes it much more inconvenient. One day it does one thing, the next day it may do something completely different. Even if I install on 2 machines, there's no guaranty that the repo owner won't push changes in the meantime.

Yeah, like .. and also, be careful with the 'plugins' of a 'keyboard' manager, kiddiez .. these are helaciously un-inspected playgrounds for harvesting. It may "improve" your developer chops, but then .. "it may not".

There are ways to change the keyboard home/end key without needing an app to download. For example, a bit of Google instead yields:

    $ cd ~/Library
    $ mkdir KeyBindings
    $ cd KeyBindings
    $ nano DefaultKeyBinding.dict
    
    Put these lines in that file, including the curly braces:
    
    {
    /* Remap Home / End keys to be correct */
    "\UF729" = "moveToBeginningOfLine:"; /* Home */
    "\UF72B" = "moveToEndOfLine:"; /* End */
    "$\UF729" = "moveToBeginningOfLineAndModifySelection:"; /* Shift + Home */
    "$\UF72B" = "moveToEndOfLineAndModifySelection:"; /* Shift + End */
    "^\UF729" = "moveToBeginningOfDocument:"; /* Ctrl + Home */
    "^\UF72B" = "moveToEndOfDocument:"; /* Ctrl + End */
    "$^\UF729" = "moveToBeginningOfDocumentAndModifySelection:"; /* Shift + Ctrl + Home */
    "$^\UF72B" = "moveToEndOfDocumentAndModifySelection:"; /* Shift + Ctrl + End */
     }

(from Matt: http://mwholt.blogspot.co.at/2012/09/fix-home-and-end-keys-o...)

Why require a third-party to do such things, developers?

And also, umm .. dotfiles, kidz? Really, just like that? wtf. Please do not encourage such glib attitudes in an article intended for 'quick action', but rather .. dissect the thing. A collection of links with explanatory text is one thing.. Take some time, this isn't homework. Dig deeper.

(+todo: grep -ir ".dict" this_article_suites_.x//)

" /* Remap Home / End keys to be correct */"

only when correct == "Windows Convention"

Home and End keys on the Mac (on applications which don't override default behaviour for these keys) are conventionally the same as old UNIX - they take you to the beginning and end of the document and not the beginning and end of the line (as on Windows).

http://en.wikipedia.org/wiki/Home_key

So how do you go to the start/end of lines then?

There are 2 options (on applications which havn't overridden default key bindings) -

a) cmd-left arrow for beginning and cmd-right arrow for end of the line.

b)emacs key bindings are available as well control-a and control-e for the beginning and end of a line.

Option a) gets slightly complicated in text entry on edit controls of browsers which have the cmd-left arrow key mapped to previous page (Firefox). In addition, a lot of multiplatform software ends up making things behave like on Windows ( Microsoft Office being one) by overriding defaults for these keys and home and end keys do take you to the beginning and end of the line there.

The point is, as developers, we can master whatever conventions matter to us. Me, personally - I use Home and End in the line context, not the document context.

So I'm quite happy knowing how to bend the computer to my will and not the other way around.

oh totally - I was just objecting to the use of the word "correct" :).

How is this any less secure than "here, download and run this executable"?

it takes a ton of work to package and upload a binary, and if you make it malicious it's right there in the dowwnload folder.

This is more like executing the current text of a web site (whatever that is) in a totally ephemeral way. That gives total plausible deniability to anyone who would serve you a particular version based on your IP, for example.... (or anything else). You're just not keeping the evidence.

I mean, you "could". But doing things this way, you're not...

I fear I'll open another can of worms, but here's a rare consideration. If I download, unzip, and then run, on-access virus scanning will hit both the archive and the executable. If I pipe from wget straight to sh, it never hits disk - and I don't know the OS internals well enough to guess whether a virus scanner can make a file handle to stdin.

And before I come off as a paranoid nut; yes I have a virus-scanner on OSX. No, I don't usually use it unless something piques my curiosity (or I'm on my employers network. Their house, their rules). But that said, I've never had my house broken into, but I still lock my door.

But for the specific examples in the article;

- Homebrew, I trust. If I'm going to trust them to patch & build every app it installs, I may as well trust their distribution mechanism.

- Dropbox, by blindly running a script from some third-party website I've never heard of? I'd rather go to dropbox.com and hit the download link.

Totally agree! I'll put a notice on the blogpost with a different way of doing this. Youre right, this can lead to bad stuff :/

You see this sort of thing more and more these days. But hey, if you can't trust something linked off of hacker news, who can you trust? ;)

Especially when the first script installs Dropbox. I was sure I wasn't the only one who read that and thought "Seriously???"

it's bad practice : yes but the source is there on github. you can always take a look. what is there to be afraid of.

On a non-github platform, it would be trivial to serve different content if the user agent was curl or wget.

The first URL isn't https. A rogue router anywhere from your building or your ISP to the server's building could potentially tamper with a plain text http response, which would then be evaluated by your shell.

well i was talking about homebrew. it uses https.

    ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

Reply on news.ycombinator.com