Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Personally, I use lzip ever since I read https://www.nongnu.org/lzip/xz_inadequate.html Seems like the complexity of XZ has backfired severely, as expected.


> Seems like the complexity of XZ has backfired severely, as expected.

this is a very bad reading of the current situation.


This kind of shallow dismissal is really unhelpful to those of us trying to follow the argument. You take a tone of authoritative expert, without giving any illuminating information to help outsiders judge the merit of your assertion. Why is it a very bad reading of the current situation? What is a better reading?


I am not sure I agree that every low quality post needs a detailed rebuttal? HN couldn't function under such rules.

as to the specific comment:

> Seems like the complexity of XZ has backfired severely, as expected.

to summarise: someone found a project with a vulnerable maintenance situation, spent years getting involved in a project, then got commit rights, and then commited a backdoor in some binaries and the build system, then got sock puppets to agitate for OSes to adopt the backdoored code.

the comment I replied to made a "shallow" claim of complexity without any details, so let's look at some possible interpretations:

- code complexity - doesn't seem super relevant - the attacker hide a highly obfuscated backdoor in a binary test file and committed it - approximately no one is ever going to catch such things without a process step of requiring binaries be generatable in a reasonable-looking and hopefully-hard-to-backdoor kind of way. cryptographers are good at this: https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

- build complexity - sure, but it's auto*, that's very common.

- organisational complexity - the opposite is the case. it had one guy maintaining it, who asked for help.

- data/file format complexity - doesn't seem relevant unless it turns out the obfuscation method used was particularly easy for this format, but even in that case, you'd think others would be vulnerable to something equivalent

perhaps OP had some other thing in mind, but then they could have said that, instead of making a crappy comment.


To summarize the article, the back door is introduced through build scripts and binaries distributed as “test” data. Very little to do with the complexity or simplicity of xz; more that it was a dependency of critical system binaries (systemd) and ripe for hostile takeover of the maintainer role.


Totally agree. This aggressive stance about xz suddenly is not even helpful to anyone. xz has been and will always be my preferred compression algorithm for times to come, despite this pitfall of really insane levels of social engineering. I feel for the author having burn out and such, but in all fairness, xz is one of the best compression formats of today's time and still going.


Introducing a back door is not the same thing as a badly designed file format.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: