4 ms·

> curl http://j.mp/spf13-vim3 http://j.mp/spf13-vim3 -L -o - | sh I'm stunned that anyone would pipe from internet to shell. No SSL and redirecting just make

> curl http://j.mp/spf13-vim3 http://j.mp/spf13-vim3 -L -o - | sh I'm stunned that anyone would pipe from internet to shell. No SSL and redirecting just make it easier for the bad guy. It makes me angry that people are promoting this as an install method. Like suggesting your first name as a good password.

spf13 14y ago
If you have any concerns there are also manual install instructions. SSL is a good idea. I should absolutely switch over to that.
- dredmorbius 14y ago
  Here's my suggestion: Post the manual installer methods. Post checksums. Sign your checksums.
erydo 14y ago
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.
- dredmorbius 14y ago
  Yes. 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.
  - erydo 14y ago
    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.
    - dredmorbius 14y ago
      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.
      - lowboy 14y ago
        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".
        dredmorbius 14y ago
- jlgreco 14y ago
  The problem is that it blurs the line between what is safe, and what is not safe. It is basically the difference between telling your users to do: wget example.com/some_script.sh ; chmod +x some_script.sh ; ./some_script.sh and: wget example.com/some_script.sh chmod +x some_script.sh ./some_script.sh 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.
  - alexkus 14y ago
    wget example.com/some_script.sh chmod +x some_script.sh ./some_script.sh is missing one very important step... wget example.com/some_script.sh chmod +x some_script.sh $EDITOR some_script.sh Only if it all looks sane/safe/sensible would I consider doing:- ./some_script.sh

spf13 14y ago

If you have any concerns there are also manual install instructions. SSL is a good idea. I should absolutely switch over to that.

dredmorbius 14y ago
Here's my suggestion: Post the manual installer methods. Post checksums. Sign your checksums.

erydo 14y ago

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.

dredmorbius 14y ago
Yes. 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.
- erydo 14y ago
  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.
  - dredmorbius 14y ago
    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.
    - lowboy 14y ago
      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".
      - dredmorbius 14y ago
jlgreco 14y ago
The problem is that it blurs the line between what is safe, and what is not safe. It is basically the difference between telling your users to do: wget example.com/some_script.sh ; chmod +x some_script.sh ; ./some_script.sh and: wget example.com/some_script.sh chmod +x some_script.sh ./some_script.sh 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.
- alexkus 14y ago
  wget example.com/some_script.sh chmod +x some_script.sh ./some_script.sh is missing one very important step... wget example.com/some_script.sh chmod +x some_script.sh $EDITOR some_script.sh Only if it all looks sane/safe/sensible would I consider doing:- ./some_script.sh