6 ms·

As the author notes: > You’re not running some random shell script from a random author, you’re running it from a software vendor who you already trust to run

As the author notes: > You’re not running some random shell script from a random author, you’re running it from a software vendor who you already trust to run software.

falcolas 7y ago
Without any form of validation that the shell script I'm running is actually from the software vendor in question. That trust is even further stretched when the request is 301 redirected to another host entirely. Between custom domain names, TLDs, Let's Encrypt (I love Let's Encrypt, but it provides is encryption, not trust) and cheeky developers using combinations of those, how can I really know that a script coming from (fictional example) https://install.dock.er https://install.dock.er is actually the Docker company?
- aequitas 7y ago
  The same arguments apply for downloading a binary. If you want to pull this even further. When is the last time you verified the signing keys of your OS distribution repo without relying on the internet? A lot of install methods that are not curl/sh are like: here copy this bash line to add apt GPG keys for our repo, apt update and install. A lot of people don't bother to check those keys.
  - falcolas 7y ago
    True, some people don't check those keys, but it's possible to do. There's a well trodden (and cryptographically secure) path for gaining trust in a key that's distinct from downloading and unpackaging a file. This is (currently) not possible to do with scripts downloaded from a web page. Especially when immediately piped into a shell.
    - aequitas 7y ago
      As with most issues in security its a balance between usability and security. The real problem is the majority of the users will always try to find the path of least resistance. No matter how well documented a secure procedure is, if a user can find a oneliner they will use it instead. I've seen this in other places as well. Vendor makes a comprehensive guide. Some people condense that to a minimum and will even boast they "made" an easier way to do X or Z, whilst ommiting all the caveats. Of course that will become the popular 'standard' people find. And they'll go complain to the vendor if it doesn't work without even reading the original instructions.
      - falcolas 7y ago
        You're not wrong with your first paragraph. That doesn't make the use of curl|sh good however. It doesn't justify developers laziness in eschewing secure methods of distribution, or writing articles like this that justify that same laziness.
eeZah7Ux 7y ago
Wrong. You are trusting much more than that, including network components outside of your control and the author's. Plus you are pushing forward the bad pattern and being part of the problem. You are encouraging other authors and users to do the same.
- aequitas 7y ago
  Tell me how this is different for downloading a binary instead. Unless you get something like a GPG through a completely different channel.
  - eeZah7Ux 7y ago
    First, distribution do exactly that. The GPG chain of trust is preinstalled. Second, there are at least 3-4 more attacks possible during curl-bash. You can simply read the links on HN.

As the author notes: > You’re not running some random shell script from a random author, you’re running it from a software vendor who you already trust to run software.

falcolas 7y ago

Without any form of validation that the shell script I'm running is actually from the software vendor in question. That trust is even further stretched when the request is 301 redirected to another host entirely. Between custom domain names, TLDs, Let's Encrypt (I love Let's Encrypt, but it provides is encryption, not trust) and cheeky developers using combinations of those, how can I really know that a script coming from (fictional example) https://install.dock.er https://install.dock.er is actually the Docker company?

aequitas 7y ago
The same arguments apply for downloading a binary. If you want to pull this even further. When is the last time you verified the signing keys of your OS distribution repo without relying on the internet? A lot of install methods that are not curl/sh are like: here copy this bash line to add apt GPG keys for our repo, apt update and install. A lot of people don't bother to check those keys.
- falcolas 7y ago
  True, some people don't check those keys, but it's possible to do. There's a well trodden (and cryptographically secure) path for gaining trust in a key that's distinct from downloading and unpackaging a file. This is (currently) not possible to do with scripts downloaded from a web page. Especially when immediately piped into a shell.
  - aequitas 7y ago
    As with most issues in security its a balance between usability and security. The real problem is the majority of the users will always try to find the path of least resistance. No matter how well documented a secure procedure is, if a user can find a oneliner they will use it instead. I've seen this in other places as well. Vendor makes a comprehensive guide. Some people condense that to a minimum and will even boast they "made" an easier way to do X or Z, whilst ommiting all the caveats. Of course that will become the popular 'standard' people find. And they'll go complain to the vendor if it doesn't work without even reading the original instructions.
    - falcolas 7y ago
      You're not wrong with your first paragraph. That doesn't make the use of curl|sh good however. It doesn't justify developers laziness in eschewing secure methods of distribution, or writing articles like this that justify that same laziness.

eeZah7Ux 7y ago

Wrong. You are trusting much more than that, including network components outside of your control and the author's. Plus you are pushing forward the bad pattern and being part of the problem. You are encouraging other authors and users to do the same.

aequitas 7y ago
Tell me how this is different for downloading a binary instead. Unless you get something like a GPG through a completely different channel.
- eeZah7Ux 7y ago
  First, distribution do exactly that. The GPG chain of trust is preinstalled. Second, there are at least 3-4 more attacks possible during curl-bash. You can simply read the links on HN.