Hacker News Reader

Comment by rytis | Hacker News Reader

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

View on HN

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.

It's not that you don't trust opscode, it's that it's possible that someone could hack opscode's installer script...

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.

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.

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.

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), people often freak out at curl commands, yet at the same time I've yet to see a viable proposal for an alternative.

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 | bash` ... was able to turn my speakers down first ;)

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.

Allow me to show you a viable proposal for an alternative:

http://manpages.ubuntu.com/manpages/precise/man8/apturl.8.ht...

As I've mentioned in 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?

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 :)

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.

Reply on news.ycombinator.com