Ignoring the SSL bit, from a security standpoint is piping to the shell really any different than saying "run this installer application"? Either way you're allowing the source to run arbitrary commands on your computer.
For me to trust an installer, implicitly, it's best for it to be part of my software distribution's package management system.
This means that the package is signed and checksummed, it's included in the distro's bugtracking system, and is being downloaded from a known set of mirrors.
Your next best option is to provide a download, checksums, and signatures, with a well-signed PGP/GPG key. At this point I can at least verify that the content is what you claim it is (whether or not that's something I plan on running is quite another matter).
Even a git repo provides a SHA1 checksum of a given commit that I can reference.
By recommending I curl-pipe-bash something, you're sending me a FLAGRANT signal that your security practices are somewhere well north of batshit crazy.
I ran into this while evaluating RVM (Ruby enVironment Manager), which itself turned out to be a requirement (or at least facilitator) for properly using Ruby for, of all things, supporting a Chef (configuration management tool) infrastructure. So ... in order to get a better handle on our server infrastructure ... the recommended and default practice is to install crap via curl-pipe-bash.
That cost us about six weeks of going through the damned installer and its effects (documentation is really poor) with a very fine-toothed comb. And I'm still not happy using it.
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.
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.
Please supply the package name, version and the output of "apt-cache policy <pkgname>". That should list where the trojaned package came from (presuming no changes to
sources.list, etc., etc.).
Packaging systems leave audit trails. Even if you get hosed, you can often figure out where and how, and take steps to both correct the upstream issue and identify and mitigate any locally affected systems (generally through a wipe/reinstall if you've got to this stage).
A good engineer will tell you that those two things are exactly the same. The reality however is that they really are not. The first is a single cohesive unit of work, from the perspective of the user. It is "easier", even though you could copy/paste the second example just as easily. The second is clearly three units of work. The story is the same, but the runon sentences have been removed. The user is almost forced to, subconsciously, ponder each step: First we download this, then we run it. Why the separation?
It is about reenforcing deliberate actions. Discrete options give the user time to interject their own thoughts.
If that isn't something that we value, then we should stop half-assing it and just give wget or curl an 'execute' flag.
