11 ms·

...The main problem is some asshat trying to install a backdoor. I use bash habitually, and every time I have an inscrutable or non-intuitive command, I pair i

...The main problem is some asshat trying to install a backdoor. I use bash habitually, and every time I have an inscrutable or non-intuitive command, I pair it with a comment explaining what it does. No exceptions. I also don't clean up after scripts for debuggability. I will offer an invocation to do the cleanup though after you've ascertained everything worked. Blaming this on bash is like a smith blaming a hammer failing on a carpenter's shoddy haft... Not terribly convincing. There was a lot of intentionally obfuscatory measures at play here and tons of weaponization of most conscientious developer's adherence to the principle of least astonishment, violations of homoglyphy (using easy to mistake filenames and mixed conventions), degenerative tool invocations (using sed as cat), excessive use/nesting of tools (awk script for the RC4 decryptor), the tr, and, to crown it all, malicious use of test data!!! As a tester, nothing makes me angrier! A pox upon them, and may their treachery be returned upon them 7-fold!

eru 3y ago
> Blaming this on bash is like a smith blaming a hammer failing on a carpenter's shoddy haft... Not terribly convincing. If your hammer is repurposed shoe, it's fair to blame the tools.
Terr_ 3y ago
> pair it with a comment A good practice, but not really a defense against malice, because if the expression is inscrutable enough to really need a comment, then it's also inscrutable enough that many people won't notice that the comment is a lie.
- salawat 3y ago
  Nothing short of reading the damn code is a defense against malice. I have yet to have any luck in getting people to actually do that.
  - cqqxo4zV46cp 3y ago
    “Why can’t humans just be better computers!” is a naive exercise in futility. This is not the answer, and completely ignores the fact that you yourself certainly make just as many mistakes as everyone else.
    - salawat 3y ago
      I'm mot asking people to be better computers. Nor do I believe myself to blissfully free of making mistakes. I'm saying, from an information propagation standpoint, it is 100% impossible for you to make a knowing based statement without having first laid eyes on the thing which you are supposed to make knowledge based statements about. This fundamental limitation on info prop will never disappear. There is nothing harder to do than to legit get somebody to actually read code.
  - Terr_ 3y ago
    Let's not get into a all-or-nothing fallacy here, my point is that there is an important security difference between: 1. Languages where obfuscation techniques look a lot like business as usual. 2. Languages where obfuscation techniques look weird compared to business as usual. The presence or lack of comments in #1 situations won't really help to bridge the gap.
    - salawat 3y ago
      You assert a dichotomy where no split really exists. Qt the end of the day, things like tr or xz or sed invocations are not part of bash as a language. They are seperate tool invocations. Python or any other programming language could have things hidden in them just as easily. And the other major issue here, is that xz is a basic system unit, often part of a bare bones, ultra basic, no fluff, embedded linux deployment where other higher level languages likely wouldn't be. It makes sense for the tools constituting the build infra to be low dependency. And yes. In a low dependency state, you have to be familiar with your working units, because by definition, you have fewer of them. Unironically, if more people weren't cripplingly dependent on luxuries like modern package managers have gotten them accustomed to, this all would have stuck out like a sore thumb, which it still did once people actually looked at the damn thing*.

eru 3y ago

> Blaming this on bash is like a smith blaming a hammer failing on a carpenter's shoddy haft... Not terribly convincing. If your hammer is repurposed shoe, it's fair to blame the tools.

Terr_ 3y ago

> pair it with a comment A good practice, but not really a defense against malice, because if the expression is inscrutable enough to really need a comment, then it's also inscrutable enough that many people won't notice that the comment is a lie.

salawat 3y ago
Nothing short of reading the damn code is a defense against malice. I have yet to have any luck in getting people to actually do that.
- cqqxo4zV46cp 3y ago
  “Why can’t humans just be better computers!” is a naive exercise in futility. This is not the answer, and completely ignores the fact that you yourself certainly make just as many mistakes as everyone else.
  - salawat 3y ago
    I'm mot asking people to be better computers. Nor do I believe myself to blissfully free of making mistakes. I'm saying, from an information propagation standpoint, it is 100% impossible for you to make a knowing based statement without having first laid eyes on the thing which you are supposed to make knowledge based statements about. This fundamental limitation on info prop will never disappear. There is nothing harder to do than to legit get somebody to actually read code.
- Terr_ 3y ago
  Let's not get into a all-or-nothing fallacy here, my point is that there is an important security difference between: 1. Languages where obfuscation techniques look a lot like business as usual. 2. Languages where obfuscation techniques look weird compared to business as usual. The presence or lack of comments in #1 situations won't really help to bridge the gap.
  - salawat 3y ago
    You assert a dichotomy where no split really exists. Qt the end of the day, things like tr or xz or sed invocations are not part of bash as a language. They are seperate tool invocations. Python or any other programming language could have things hidden in them just as easily. And the other major issue here, is that xz is a basic system unit, often part of a bare bones, ultra basic, no fluff, embedded linux deployment where other higher level languages likely wouldn't be. It makes sense for the tools constituting the build infra to be low dependency. And yes. In a low dependency state, you have to be familiar with your working units, because by definition, you have fewer of them. Unironically, if more people weren't cripplingly dependent on luxuries like modern package managers have gotten them accustomed to, this all would have stuck out like a sore thumb, which it still did once people actually looked at the damn thing*.