9 ms·

Why would I bother copying and pasting the code to my clipboard when common industry practice now is just to invoke the output of curl directly? ruby -e "$(cur

Why would I bother copying and pasting the code to my clipboard when common industry practice now is just to invoke the output of curl directly? ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go https://raw.github.com/mxcl/homebrew/go)

somesay 14y ago
You are trusting some third-party everytime you download a proprietary or just big open-source app. Even on Open Source, you just have trust in the public review. In that example you can read the source before, the chances of an evil change just when loading it with your terminal is quite limited, MITM doesn't work that well on SSL, too.
rytis 14y ago
Really sad, especially when something like Chef-client is also installed in a similar fashion [0], one would expect these guys to know better: sudo true && curl -L https://www.opscode.com/chef/install.sh | sudo bash [0] http://wiki.opscode.com/display/chef/Installing+Omnibus+Chef+Client+on+Linux+and+Mac http://wiki.opscode.com/display/chef/Installing+Omnibus+Chef...
- FooBarWidget 14y ago
  Know better... in order to do what? They also provide an APT repository, which you can choose to use instead of the curl command. The curl command exists solely for convenience, because it autodetects your OS, distro version, and automatically registers the right APT repository for you if you're on Debian. As I've mentioned here (https://news.ycombinator.com/item?id=5508680 https://news.ycombinator.com/item?id=5508680), people often freak out at curl commands, yet at the same time I've yet to see a viable proposal for an alternative.
  - mscarborough 14y ago
    Well, the downloaded bash script does all that, and a user is always free to leave the last piping-into-bash command off. They can review it first, and then run as sudo (or whoever) if it passes muster. It's not that much different, so I don't understand the huge problem. Most likely if tutorial writers added a second step, the user would just copypasta the second step also. Thankfully I followed this procedure after a co-worker sent me this: `curl -L http://bit.ly/10hA8iC http://bit.ly/10hA8iC | bash` ... was able to turn my speakers down first ;)
    - laumars 14y ago
      That's one of the better rickrolling I've seen! One of my mates rickrolled me by post (aka snail mail) just days after I moved house. It took me 2 years to find out who was behind that.
  - cmsj 14y ago
    Allow me to show you a viable proposal for an alternative: http://manpages.ubuntu.com/manpages/precise/man8/apturl.8.html http://manpages.ubuntu.com/manpages/precise/man8/apturl.8.ht...
    - FooBarWidget 14y ago
      As I've mentioned in https://news.ycombinator.com/item?id=5508680 https://news.ycombinator.com/item?id=5508680, for any alternative to be viable it must "work on all major platforms". APT is only used in Debian derivatives. How do you want to handle OS X users?
      - cmsj 14y ago
        Give them a DMG? It would be lovely if there was a One True Software Distribution Format, but it's not going to happen. wgetting into a bash script is a terrible way to not really support any users properly :)
        FooBarWidget 14y ago
        Neither is it going to happen that every developer spends considerable resources on creating packages for every platform. Just look at the popularity of curl installs, or even at the number of developers who don't bother to provide binaries and stick to source tarballs.
- trotsky 14y ago
  So you're trusting opscode to provide the primary centralized control system of your entire server ecosystem but you're concerned they might be embedding something malicious in their installer shell script? Don't get me wrong, i'm no fan of the practice especially sans tls, but this seems like a poor example.
  - nicksergeant 14y ago
    It's not that you don't trust opscode, it's that it's possible that someone could hack opscode's installer script...
    - trotsky 14y ago
      just like they could replace a binary, backdoor the Makefile or hide something bad deep in the repo. And of course their hash of their signing key for their apt repo and any shasums are provided on the same webserver.
      - cmsj 14y ago
        Of course that is always a risk, but with most FOSS software being maintained in public revision control systems, it's difficult to truly hide something. Even if you discard the security angle of wget | bash (which you would be a foolish choice) there is the simple problem of repeatability. If you are deploying 50 new servers and OpsCode releases a new version of Chef after 25 of the servers have performed the wget, the next 25 will get a different client that might be incompatible with the server.
        trotsky 14y ago
        For what it's worth, that curl install is a "beachhead" install. When you provision servers you load chef on them using knife bootsrap, which carefully ensures it installs the revision of chef on the server that you're using on the management workstation. You have to go out of your way to get a brand new release installed on a node if you haven't installed it on your workstation.
subway 14y ago
C'mon... That is nothing like the industry standard -- you used SSL.
- somesay 14y ago
  Watch out. Does curl check the key chain against any key store? I bet not.
  - lnguyen 14y ago
    Actually it does. You turn off checking via -k
    - somesay 14y ago
      Oh, nice, you are right, should be compiled against OS' key storage. Actually it's wget who often doesn't care of that.
      - lukeschlather 14y ago
        Wget has the --no-check-certificate flag, I've had to use it to work with self-signed certs before.
      - LukeShu 14y ago
        Um, GNU wget does check the key, and it requires the lengthy `--no-check-certificate` to disable it. Perhaps busybox wget doesn't check the key? But if you're using busybox, that's a whole other can of worms.
        0xbadcafebee 14y ago
        Wget does not validate certificates by default because there's no CA bundle provided with wget. It does check for /etc/ssl/cert.pem, but it doesn't provide one. So you have to provide one or set up /etc/ssl/certs/ as OpenSSL libraries expect. Curl does provide a CA bundle (/usr/share/curl/ca-bundle.crt) and by default libcurl validates certs against it.
ivix 14y ago
Why would you say that is industry practice when it is not?
- carb 14y ago
  It's the suggested install for homebrew. http://mxcl.github.io/homebrew/ http://mxcl.github.io/homebrew/
  - FooBarWidget 14y ago
    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.
    - Scaevolus 14y ago
      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.
      - FooBarWidget 14y ago
        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.
anonymoushn 14y ago
I was quite surprised when this was the normal way of installing rvm: https://rvm.io/rvm/install/ https://rvm.io/rvm/install/
- SkyMarshal 14y ago
  Hence why many use rbenv instead. https://github.com/sstephenson/rbenv/#neckbeard-configuration https://github.com/sstephenson/rbenv/#neckbeard-configuratio... https://github.com/sstephenson/rbenv/wiki/Why-rbenv%3F https://github.com/sstephenson/rbenv/wiki/Why-rbenv%3F
  - Zr40 14y ago
    For me, the method of installation is one of the less important reasons why I started using rbenv instead of rvm. rbenv's simplicity and speed appealed to me, and the trigger for switching was rvm destroying itself again (or otherwise rendering itself unusable) after updating it.
q_revert 14y ago
one of the recommended ways to install oh-my-zsh wget --no-check-certificate https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh
- fnordfnordfnord 14y ago
  Don't forget 'sudo'!
  - zsiciarz 14y ago
    You don't need sudo as this is your user's shell.
nkvoll 14y ago
Are you going to type that string into your terminal manually, or are you just copy/pasting that line from a web page, still leaving yourself open to this issue? I find it hard to believe anyone will be reading that line on a web page, then typing it out correctly in their own terminal instead of just saying, "ok that line looks fine copy paste"
- hac 14y ago
  I might copy the command, quickly paste it in my URL bar to make sure it is indeed what I expected, and then paste it into Terminal
charlieok 14y ago
I dislike this whole trend. How about we start thinking in terms of leaving the user's default environment, and system, alone, and “installing” software into nice sandboxed areas where we can easily enable/disable it, or delete it with a simple “rm -rf directory/path”
- arjunbajaj 14y ago
  I would love to use such a thing! I'm bugged with programs I don't use anymore which start on system boot. Even after removing some programs, they just don't go away. A sandboxed environment would be really good to use!
  - jhasse 14y ago
    http://www.gobolinux.org/ http://www.gobolinux.org/ unfortunately it seems to be dead.
  - laumars 14y ago
    That's just bad administration as even on Windows, you can easily disable them (msconfig). With Linux, this isn't even an issue unless you're blindly installing dozens of daemons (which, again, can easily be disabled) as Linux doesn't have hundreds of application launchers that install themselves like Windows does (again, daemons being the exception). The only example I can think of where you might run into problems is if your desktop environment is doing some weird sessions. But that's usually fixed pretty easily in the system settings for whatever desktop environment you're running. This is all pretty basic stuff; you shouldn't need a sandboxed environment to prevent applications from auto-launching unless you're going around installing malware (and if you are deliberately installing malware on your main bare-metal OS, then you're insane).
    - nitrogen 14y ago
      This may have been true 5-10 years ago, but modern desktops are removing the ability to manage services, sessions, and startup apps easily and clearly.
Kiro 14y ago
I don't understand what this has to do with copying or pasting at all. I would still copy-paste it.

somesay 14y ago

You are trusting some third-party everytime you download a proprietary or just big open-source app. Even on Open Source, you just have trust in the public review. In that example you can read the source before, the chances of an evil change just when loading it with your terminal is quite limited, MITM doesn't work that well on SSL, too.

rytis 14y ago

Really sad, especially when something like Chef-client is also installed in a similar fashion [0], one would expect these guys to know better: sudo true && curl -L https://www.opscode.com/chef/install.sh | sudo bash [0] http://wiki.opscode.com/display/chef/Installing+Omnibus+Chef+Client+on+Linux+and+Mac http://wiki.opscode.com/display/chef/Installing+Omnibus+Chef...

FooBarWidget 14y ago
Know better... in order to do what? They also provide an APT repository, which you can choose to use instead of the curl command. The curl command exists solely for convenience, because it autodetects your OS, distro version, and automatically registers the right APT repository for you if you're on Debian. As I've mentioned here (https://news.ycombinator.com/item?id=5508680 https://news.ycombinator.com/item?id=5508680), people often freak out at curl commands, yet at the same time I've yet to see a viable proposal for an alternative.
- mscarborough 14y ago
  Well, the downloaded bash script does all that, and a user is always free to leave the last piping-into-bash command off. They can review it first, and then run as sudo (or whoever) if it passes muster. It's not that much different, so I don't understand the huge problem. Most likely if tutorial writers added a second step, the user would just copypasta the second step also. Thankfully I followed this procedure after a co-worker sent me this: `curl -L http://bit.ly/10hA8iC http://bit.ly/10hA8iC | bash` ... was able to turn my speakers down first ;)
  - laumars 14y ago
    That's one of the better rickrolling I've seen! One of my mates rickrolled me by post (aka snail mail) just days after I moved house. It took me 2 years to find out who was behind that.
- cmsj 14y ago
  Allow me to show you a viable proposal for an alternative: http://manpages.ubuntu.com/manpages/precise/man8/apturl.8.html http://manpages.ubuntu.com/manpages/precise/man8/apturl.8.ht...
  - FooBarWidget 14y ago
    As I've mentioned in https://news.ycombinator.com/item?id=5508680 https://news.ycombinator.com/item?id=5508680, for any alternative to be viable it must "work on all major platforms". APT is only used in Debian derivatives. How do you want to handle OS X users?
    - cmsj 14y ago
      Give them a DMG? It would be lovely if there was a One True Software Distribution Format, but it's not going to happen. wgetting into a bash script is a terrible way to not really support any users properly :)
      - FooBarWidget 14y ago
        Neither is it going to happen that every developer spends considerable resources on creating packages for every platform. Just look at the popularity of curl installs, or even at the number of developers who don't bother to provide binaries and stick to source tarballs.
trotsky 14y ago
So you're trusting opscode to provide the primary centralized control system of your entire server ecosystem but you're concerned they might be embedding something malicious in their installer shell script? Don't get me wrong, i'm no fan of the practice especially sans tls, but this seems like a poor example.
- nicksergeant 14y ago
  It's not that you don't trust opscode, it's that it's possible that someone could hack opscode's installer script...
  - trotsky 14y ago
    just like they could replace a binary, backdoor the Makefile or hide something bad deep in the repo. And of course their hash of their signing key for their apt repo and any shasums are provided on the same webserver.
    - cmsj 14y ago
      Of course that is always a risk, but with most FOSS software being maintained in public revision control systems, it's difficult to truly hide something. Even if you discard the security angle of wget | bash (which you would be a foolish choice) there is the simple problem of repeatability. If you are deploying 50 new servers and OpsCode releases a new version of Chef after 25 of the servers have performed the wget, the next 25 will get a different client that might be incompatible with the server.
      - trotsky 14y ago
        For what it's worth, that curl install is a "beachhead" install. When you provision servers you load chef on them using knife bootsrap, which carefully ensures it installs the revision of chef on the server that you're using on the management workstation. You have to go out of your way to get a brand new release installed on a node if you haven't installed it on your workstation.

subway 14y ago

C'mon... That is nothing like the industry standard -- you used SSL.

somesay 14y ago
Watch out. Does curl check the key chain against any key store? I bet not.
- lnguyen 14y ago
  Actually it does. You turn off checking via -k
  - somesay 14y ago
    Oh, nice, you are right, should be compiled against OS' key storage. Actually it's wget who often doesn't care of that.
    - lukeschlather 14y ago
      Wget has the --no-check-certificate flag, I've had to use it to work with self-signed certs before.
    - LukeShu 14y ago
      Um, GNU wget does check the key, and it requires the lengthy `--no-check-certificate` to disable it. Perhaps busybox wget doesn't check the key? But if you're using busybox, that's a whole other can of worms.
      - 0xbadcafebee 14y ago
        Wget does not validate certificates by default because there's no CA bundle provided with wget. It does check for /etc/ssl/cert.pem, but it doesn't provide one. So you have to provide one or set up /etc/ssl/certs/ as OpenSSL libraries expect. Curl does provide a CA bundle (/usr/share/curl/ca-bundle.crt) and by default libcurl validates certs against it.

ivix 14y ago

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

carb 14y ago
It's the suggested install for homebrew. http://mxcl.github.io/homebrew/ http://mxcl.github.io/homebrew/
- FooBarWidget 14y ago
  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.
  - Scaevolus 14y ago
    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.
    - FooBarWidget 14y ago
      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.

anonymoushn 14y ago

I was quite surprised when this was the normal way of installing rvm: https://rvm.io/rvm/install/ https://rvm.io/rvm/install/

SkyMarshal 14y ago
Hence why many use rbenv instead. https://github.com/sstephenson/rbenv/#neckbeard-configuration https://github.com/sstephenson/rbenv/#neckbeard-configuratio... https://github.com/sstephenson/rbenv/wiki/Why-rbenv%3F https://github.com/sstephenson/rbenv/wiki/Why-rbenv%3F
- Zr40 14y ago
  For me, the method of installation is one of the less important reasons why I started using rbenv instead of rvm. rbenv's simplicity and speed appealed to me, and the trigger for switching was rvm destroying itself again (or otherwise rendering itself unusable) after updating it.

q_revert 14y ago

one of the recommended ways to install oh-my-zsh wget --no-check-certificate https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

fnordfnordfnord 14y ago
Don't forget 'sudo'!
- zsiciarz 14y ago
  You don't need sudo as this is your user's shell.

nkvoll 14y ago

Are you going to type that string into your terminal manually, or are you just copy/pasting that line from a web page, still leaving yourself open to this issue? I find it hard to believe anyone will be reading that line on a web page, then typing it out correctly in their own terminal instead of just saying, "ok that line looks fine copy paste"

hac 14y ago
I might copy the command, quickly paste it in my URL bar to make sure it is indeed what I expected, and then paste it into Terminal

charlieok 14y ago

I dislike this whole trend. How about we start thinking in terms of leaving the user's default environment, and system, alone, and “installing” software into nice sandboxed areas where we can easily enable/disable it, or delete it with a simple “rm -rf directory/path”

arjunbajaj 14y ago
I would love to use such a thing! I'm bugged with programs I don't use anymore which start on system boot. Even after removing some programs, they just don't go away. A sandboxed environment would be really good to use!
- jhasse 14y ago
  http://www.gobolinux.org/ http://www.gobolinux.org/ unfortunately it seems to be dead.
- laumars 14y ago
  That's just bad administration as even on Windows, you can easily disable them (msconfig). With Linux, this isn't even an issue unless you're blindly installing dozens of daemons (which, again, can easily be disabled) as Linux doesn't have hundreds of application launchers that install themselves like Windows does (again, daemons being the exception). The only example I can think of where you might run into problems is if your desktop environment is doing some weird sessions. But that's usually fixed pretty easily in the system settings for whatever desktop environment you're running. This is all pretty basic stuff; you shouldn't need a sandboxed environment to prevent applications from auto-launching unless you're going around installing malware (and if you are deliberately installing malware on your main bare-metal OS, then you're insane).
  - nitrogen 14y ago
    This may have been true 5-10 years ago, but modern desktops are removing the ability to manage services, sessions, and startup apps easily and clearly.

Kiro 14y ago

I don't understand what this has to do with copying or pasting at all. I would still copy-paste it.