8 ms·

It looks really awesome. Thanks. This anti-pattern is a bit of a red flag for me though: bash -c "$(curl -fsSL http://gef.blah.cat/sh)"

Graziano_M 5y ago
It certainly is. I don't install it that way, or recommend it be installed that way, but others do. You can take that up with the project owner :)
dahfizz 5y ago
I've never understood why this gets so much hate. You are downloading and running their python script anyway. Why do you trust their software but not their install script? The fact that it is hosted on http is suboptimal, but it does redirect to an https github page in this case
- mistrial9 5y ago
  the difference includes -- a physical computer you use and care about, need to trust, with a lot of setup and your own efforts involved, may be a single-point endpoint with value and/or state, which is by definition vulnerable versus an ephemeral VM or Docker that is repeatedly created and destroyed in moments, has almost no lasting value since a new one is only a minute away, and has no personal value or customization.
- mortenlarsen 5y ago
  For me it is because it normalizes bad practice. There is a reason we have packages and signatures. It is not as bad as: curl something | sh Where you can detect on the server side that the download goes into a pipe (due to buffering) and serve different versions of the file depending on if you are downloading it or executing it directly, but it is still bad practice.
  - charcircuit 5y ago
    How is running a script from a downloaded package any better than running a script from a download script?
    - mortenlarsen 5y ago
      The script can change any time, and maybe even just for some people without leaving a trace. Updating a package in a OS distribution repository requires that it is signed, and spread to all the mirrors (it is unlikely that an attacker controls all of them). This makes it more likely to be discovered and hard to do targeted attacks without leaving a trace. If it does happen that you are compromised using: bash -c "$(curl -fsSL http://gef.blah.cat/sh)" How will you find out afterwards, that this is what happened? I run local mirrors of everything I use (with snapshots after updating the mirror), so I at least have a history of the software that I ran to do forensics on. I could not do that if I ran scripts directly from the Internet into a shell. For example: Something suddenly trying to connect to the Internet (or doing DNS lookups) from one of my segregated systems might prompt me to investigate. Even if you are not so "paranoid" as many would call it (I would call it being diligent), you still get the benefit of others being "paranoid". So making sure (via packages, mirrors and signatures) that we all get the same "version" of software is important for security.
  - edgyquant 5y ago
    How can you detect that it’s going to a pipe?
    - kccqzy 5y ago
      The shell reads a command and then executes it. It doesn't buffer the whole script into memory.
    - Arnavion 5y ago
      https://news.ycombinator.com/item?id=17636032 https://news.ycombinator.com/item?id=17636032
NavinF 5y ago
I love that anti-pattern. It gets people thinking. It’s not like anyone is gonna download that script, find out what the script downloads, and then read every line of the whole project and its dependencies to see if one of them installs a rootkit.
stjohnswarts 5y ago
I sorta agree with you but only because it's an http site which allows easy MITM attacks . Otherwise, you're going to be downloading a shell script and executing it. You are trusting your system to a blind executable either way. Same with using pip, choco, rpm, brew, dnf, etc.
- worthless-trash 5y ago
  Except with dnf you need signed rpms or to have explicitly disabled gpg checks to install unsigned packages from a 'trusted' source. Ie, much harder to MITM.
deleted 5y ago
[deleted]
SubjectToChange 5y ago
The directions for manual installation are listed directly after that. The first page of the documentation even explains how to install it directly from the repo. Also, it's funny that "curling to shell" is what crosses the line. As if any of the installation options even approach the risk of appending .gdbinit with over ten thousand lines of unaudited python, especially in a privileged environment like a debugger. Curling to shell is not particularly dangerous than the alternatives.

Graziano_M 5y ago

It certainly is. I don't install it that way, or recommend it be installed that way, but others do. You can take that up with the project owner :)

dahfizz 5y ago

I've never understood why this gets so much hate. You are downloading and running their python script anyway. Why do you trust their software but not their install script? The fact that it is hosted on http is suboptimal, but it does redirect to an https github page in this case

mistrial9 5y ago
the difference includes -- a physical computer you use and care about, need to trust, with a lot of setup and your own efforts involved, may be a single-point endpoint with value and/or state, which is by definition vulnerable versus an ephemeral VM or Docker that is repeatedly created and destroyed in moments, has almost no lasting value since a new one is only a minute away, and has no personal value or customization.
mortenlarsen 5y ago
For me it is because it normalizes bad practice. There is a reason we have packages and signatures. It is not as bad as: curl something | sh Where you can detect on the server side that the download goes into a pipe (due to buffering) and serve different versions of the file depending on if you are downloading it or executing it directly, but it is still bad practice.
- charcircuit 5y ago
  How is running a script from a downloaded package any better than running a script from a download script?
  - mortenlarsen 5y ago
    The script can change any time, and maybe even just for some people without leaving a trace. Updating a package in a OS distribution repository requires that it is signed, and spread to all the mirrors (it is unlikely that an attacker controls all of them). This makes it more likely to be discovered and hard to do targeted attacks without leaving a trace. If it does happen that you are compromised using: bash -c "$(curl -fsSL http://gef.blah.cat/sh)" How will you find out afterwards, that this is what happened? I run local mirrors of everything I use (with snapshots after updating the mirror), so I at least have a history of the software that I ran to do forensics on. I could not do that if I ran scripts directly from the Internet into a shell. For example: Something suddenly trying to connect to the Internet (or doing DNS lookups) from one of my segregated systems might prompt me to investigate. Even if you are not so "paranoid" as many would call it (I would call it being diligent), you still get the benefit of others being "paranoid". So making sure (via packages, mirrors and signatures) that we all get the same "version" of software is important for security.
- edgyquant 5y ago
  How can you detect that it’s going to a pipe?
  - kccqzy 5y ago
    The shell reads a command and then executes it. It doesn't buffer the whole script into memory.
  - Arnavion 5y ago
    https://news.ycombinator.com/item?id=17636032 https://news.ycombinator.com/item?id=17636032

NavinF 5y ago

I love that anti-pattern. It gets people thinking. It’s not like anyone is gonna download that script, find out what the script downloads, and then read every line of the whole project and its dependencies to see if one of them installs a rootkit.

stjohnswarts 5y ago

I sorta agree with you but only because it's an http site which allows easy MITM attacks . Otherwise, you're going to be downloading a shell script and executing it. You are trusting your system to a blind executable either way. Same with using pip, choco, rpm, brew, dnf, etc.

worthless-trash 5y ago
Except with dnf you need signed rpms or to have explicitly disabled gpg checks to install unsigned packages from a 'trusted' source. Ie, much harder to MITM.

deleted 5y ago

[deleted]

SubjectToChange 5y ago

The directions for manual installation are listed directly after that. The first page of the documentation even explains how to install it directly from the repo. Also, it's funny that "curling to shell" is what crosses the line. As if any of the installation options even approach the risk of appending .gdbinit with over ten thousand lines of unaudited python, especially in a privileged environment like a debugger. Curling to shell is not particularly dangerous than the alternatives.