Hacker News Reader

Comment by mrb | Hacker News Reader

To be clear: the build system did not use the code fragment you quoted. This complex awk code is a later stage of the backdoor.

View on HN

I see, my point was more than this shouldn’t be allowed. I think part of the problem with a lot of things is we’re allowing complexity for the sake of complexity.

No one has simplicity-required checks. My previous post should say “allows things like this”.

Unless I’m misunderstanding, all this code was embedded and hidden inside the obfuscated test files.

None of this would have been visible in commits or diffs at all.

But what are you suggesting exactly? The code fragment you quoted was awk code. Awk is a generic programming language. Any programming language can be written to be complex and unreadable.

> Any programming language can be written to be complex and unreadable. The question is you as lead developer, reviewing a commit with a complex and unreadable code snippet, what would you do?

You would reject it of course, which is exactly why this code never appeared in a commit. The stage 0 of the exploit was not checked in, but directly added to the autogenerated build script in the release tarball, where, even if someone did review the script, it looks plausibly like other autogenerated build gunk. The complex and unreadable scripts in the further stages were hidden inside binary test files, so no one reviewing the commit that added them (https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b) would directly see that code.

But this awk code was not committed in the clear so it was not possible to review. It was hidden in a binary file, compressed and encrypted.

Your point is likely entirely valid, but the example you used is the wrong one.

Who “allowed things like this”? - this was obfuscated behind a binary posing as an actually corrupt “test” file.

Reply on news.ycombinator.com