Hacker News Reader

Comment by erydo | Hacker News Reader

First: I'm not recommending anything—I'm asking a question. This isn't my practice but it's important to play devil's advocate sometimes.

Second, the question was not whether piping to shell is a good way of doing installations. The question was whether it's actually worse than the common method of offering up an untrusted downloadable executable.

Many (or most) consumer software downloads that you'll find for Mac or Windows don't meet any of the criteria you specified (which I agree are good criteria). But that wasn't the question: Is it actually worse than offering an untrusted executable? People don't seem to complain about those as much, but to me they seem equivalently bad.

View on HN

At the very least, pipe-to-shell means you're left without an audit trail, if you're actually practicing that method.

With a downloadable executable or installer, I'm left with a file that I can save, checksum, scan for vulnerabilities, and/or refer to at a later date should I find that there are concerns I didn't discover initially.

curl-pipe-bash, especially in the absence of SSL/TLS, leaves me vulnerable to injection attacks, as well as invisible changes to the installer (so I don't know whether or not things have changed if I'm trying the same process later).

It's a very, very, very bad idea.

My prediction: this will all end in tears sooner or later. I'm actually hoping for sooner just so we can put an end to this foolishness.

As for Windows: I don't play there often, but my understanding is that most executables are now signed, so that the "download random binary from arbitrary website, run as Administrator" practice is at least very slightly less batshit insane than in the past.

While I agree 100% with your advice for mission-critical servers, for a dev machine I don't see the problem with the ease of curl -> sh. It takes "very very very bad idea" down to "you probably should at least check out the installer script first".

Where do you think that code for mission-critical servers gets developed?

There's a pretty scary amount of iffy public code that ends up on mission-critical servers. I could outline some chains of connection, but briefly: it's very easy for someone's cheesy little website to become a significant player in another organization's processing.

That "website" you're going to likely runs not only on multiple servers, but in multiple datacenters across multiple organizational borders: core site, sales, support, order fulfillment, marketing analytics, web analytics, email, messaging, social integration ....

The best way not to get into bad habits on your production, mission-critical systems is to not allow them anywhere else.

Granted, this is a Vim suite, but I'm seeing similar brain death in far too many corners.

If someone is actively trying to be a mitm and injecting things into your connection - you have far far worse problems than corrupted software.

Reply on news.ycombinator.com