News for hackers. Stuff that matters.
Re:The xz attack shell script by Terr_ on Wednesday April 03, 2024 @04:50AM (#39914951)
> 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.

Re:The xz attack shell script by salawat on Wednesday April 03, 2024 @03:29PM (#39921942)
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.
Re:The xz attack shell script by cqqxo4zV46cp on Wednesday April 03, 2024 @07:31PM (#39924708)
“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.
Re:The xz attack shell script by salawat on Thursday April 04, 2024 @11:37AM (#39931772)
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.

Re:The xz attack shell script by Terr_ on Wednesday April 03, 2024 @09:34PM (#39925590)
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.

Re:The xz attack shell script by salawat on Thursday April 04, 2024 @11:52AM (#39931974)
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*.