5 ms·
> curl -s http://getmacapps.com/raw/6bl http://getmacapps.com/raw/6bl | sh > ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)" https://raw.github
by mellamoyo 13y ago
> curl -s http://getmacapps.com/raw/6bl http://getmacapps.com/raw/6bl | sh
> ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)" 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.
- altryne1 13y agoTotally agree! I'll put a notice on the blogpost with a different way of doing this. Youre right, this can lead to bad stuff :/
- vondur 13y agoYou 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? ;)
- tuananh 13y agoit's bad practice : yes but the source is there on github. you can always take a look. what is there to be afraid of.
- btgeekboy 13y agoOn a non-github platform, it would be trivial to serve different content if the user agent was curl or wget.
- ultimoo 13y agoThe 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.
- tuananh 13y agowell i was talking about homebrew. it uses https. ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
- alex_anglin 13y agoEspecially when the first script installs Dropbox. I was sure I wasn't the only one who read that and thought "Seriously???"
- fishtoaster 13y agoI 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.
- kbutler 13y agoIt's also at least as safe as downloading and running a binary executable.
- falcolas 13y agoI 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.
- kbutler 13y agocurl -s foo.com/bar | sh vs 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.
- bithive123 13y agoHow is this any less secure than "here, download and run this executable"?
- logicallee 13y agoit 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...
- soneil 13y agoI 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.
- rytis 13y agoI 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.
- fit2rule 13y agoYeah, 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-on-mac-os-x.html 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//)
- vvhn 13y ago" /* 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 http://en.wikipedia.org/wiki/Home_key
- waylonrobert 13y agoSo how do you go to the start/end of lines then?