This could be a direct response to the concerns you voiced in the Pow thread a couple days back. And your input is on word choice? Jeesh, someone's hard to please :)
This doesn't answer your question but here I think is a good place for me to spell out what actually happened between the Pow thread and here:
* Sam Stephenson posted Pow with instructions to install it by piping curl http:// into sh.
* I posted a comment calling that installer directive "borderline irresponsible", while at the same time attempting to convey being impressed with Pow itself. My execution of the message I am trying to convey is not graceful.
* Because I have better name recognition on HN and also an unasked-for but not unappreciated status as HN resident security dork, my comment shot up to the top of the thread.
* Because HN is a community of nerds, a bunch of people jumped on to say (in effect) "hey wait, people are also at risk when they install software from Rubygems, but you don't call Rubygems out".
* I responded to some of these comments. I was careful at first because wow is this a boring argument, and more careful later because wow did that comment thread ever spin out of control.
* At this point, 2/3rds of the comments on the thread are nerds arguing about (or, more accurately, piling on to one side of the argument or the other) curl|sh installers.
* Here I decide to edit my comment to note that it sucks that this argument is taking over the thread, because Pow is pretty cool. I see it as an appeal to please downvote my comment because it isn't germane to Pow.
* Sam Stephenson posts a comment thanking someone else for praising Pow, because he's happy not to see FUD about Pow. I now feel very bad, because I can see why he feels FUD'd. I'm having a bad week, so I don't communicate this very gracefully.
* Sam, obviously still stung (or amused) by the HN debacle, posts "gosh", a program that makes fun of the notion that you shouldn't pipe web pages into sh.
Here we are a little stuck. I don't know Sam, but I know the team he works for and admire it. On the other hand, I do know that curl|sh is a bad idea and am not going to say it's a good idea just because HN commenting dynamics, whether my fault or not, spun out of control. It doesn't matter how much I like 37signals. I still have to rely on my judgement. I may be wrong, but from what I can perceive now, curl|sh is evil.
I have respect for both Tom and Sam, but Tom is in his domain here (even if he's only willing to commit to a vague feeling of unease...I trust those feelings from certain people).
Curl sends page output to STDOUT regardless of http response code. So, if the URI in the command line is typo'ed or if the install script is moved, or the webserver config is borked, etc, the error page gets sent to the shell for execution. Also if the ISP proxy or some other evil bit is broken or unauthenticated-to.
Most of the time it'll be harmless, but it's a factor that is completely out of the control of the developer of the software you intended to run.
And sometimes it might not be harmless. A custom 404 page with inline CSS, or even helpful text could easily contain a command on a parsed newline, or after a semicolon. Hijinx could ensue.
PS: yes, Pow is super cool and I already love it. But the recommended installation method is too clever for its own good. Damn you Ximian.
Thanks for the citation. I'll include that comment at the bottom of this one for reference.
There are two other points I neglected to make in detail previously.
* curl does not have root certs by default so curl https:// no good. In fact, it won't even work (and rightly so):
$ curl https://google.com
curl: (60) SSL certificate problem, verify that the CA cert is OK.
Details:
...
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
Going through the process to generate a cert bundle is much harder than installing RubyGems or any other package installer that supports signed packages.
* XSS or similar failures that don't involve complete control of the server lead to code execution on the client.
You don't want to make common security flaws on the server result in instant compromise of the client.
While I think the author of "gosh" may consider this a fun little joke, he's picked the wrong side of this issue. Where's the tool making fun of JS crypto? Now that's security theater.
Previous comment with other points:
* No transport security. As many people mention, at least adding HTTPS would help with this. However, most non-browser SSL clients (wget, curl) don't include any root certs by default so even switching to SSL would not help this method. Firesheep, sslstrip, etc. automatically generate a self-signed cert which would look no different to wget than a real cert.
* No persistence. If you download any installer package once and then reuse it on multiple machines, you get the benefit of knowing that the same code was installed on each machine (good or bad). With this method, users may catch the site in the middle of an update and get multiple versions of the package.
* No authentication. Even with SSL, you only get strong transport security. You would know strongly that ".pow.cx" sent you some code, but not how that code got put on the server. With package-signing, typically done on the developer's end system, you know that it was protected even before it was uploaded to some site.
* Easier to trojan than binaries. Inserting a few extra shell commands in a single HTTP(S) session (say, targeting a single client IP) is much easier than building a custom binary package. Consider how hard it is to even compile Firefox with all the dependencies. Now do that work and insert a trojan and upload a separate 10 MB binary that needs to be stored somewhere on the server while waiting for that one client to visit the site. Compare this to keeping a two-line patch to a shell script (easily done in RAM, maybe even by hotpatch).
* Trains users that all the above is ok since the popularity of this "| sh" install method is relatively new. (Yes, I know about shar scripts in the past but those ended by 1996 or so with the advent of real package managers). It is absolutely impossible to retrofit "| sh" to be secure, whereas it is definitely feasible to add package signature verification support to gem or yum or apt or whatever (in fact, all those already support it).
The fact that many installers aren't signed today is not an ok to drive this process back to the 80's. We should be moving toward the future when package signing is a required part of being a software developer. Too hard? Well build tools to make this easier!
It may be possible that I am just insane right now. It's been... a week. I think I'm going to take this message board argument and drown it in a bottle of rye.
