Live data from Hacker News

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

21–30 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#21
post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

>4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencies and most programs use a tiny fraction of it. Encouraging every service to depend on it for initialization notifications is insane.

They never did. In fact the systemd maintainers are confused on that point and adding documentation on how to implement the simple datagram without libsystemd.

>7. We need to make OSS work from the financial point of view for developers. Liblzma and xz-utils probably have tens of millions of install but a single maintainer with mental health problems.

Way more than tens of millions. Python, php, ruby and many other languages depend on libxml2, libxml2 uses liblzma. And there's many other dependencies.

>8. This sucks to say, but code reviews and handing off maintainership, at the moment, need to take into account geopolitical considerations.

Not any maintainer's job. OSS is provided without warranty. Also indication is "Jia Tan" may have been completely fake as their commit timestamps show even on the same day that their timezone switches from Eastern Europe to Asia. So at the very least, they were playing identity games.

Re: What we know about the xz Utils backdoor that almost infected the world

#22
post #4

Are we ever going to figure out who Jia Tan is?

If it was state-sponsored (considering the timeline, that's a real possibility), then "Jia Tan" could actually be a collection of folks, working for the same team.

Re: What we know about the xz Utils backdoor that almost infected the world

#23
post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

I would personally add: test your build scripts.

There are so many bugs like the "added dot to disable landlock" added as part of this action (which can also be typos [0]), not to mention that relying on some tools in autoconf to set feature flags will just disable them if those tools are not present [1].

[0] https://twitter.com/disconnect3d_pl/status/17744965092596453...

[1] https://twitter.com/disconnect3d_pl/status/17747470223623252...

Re: What we know about the xz Utils backdoor that almost infected the world

#24
post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

> 1a. As a consequence of (1) autogenerated artifacts should always be committed.

Or… just have downstream users run autotools as part of the build?

Re: What we know about the xz Utils backdoor that almost infected the world

#26
post #11

I’m guessing the original maintainer of xz handed responsibilities to Jia Tan without ever seeing him/her or at least sharing a phone call. Is that common to only communicate only through email/github? I guess some maintainers of open source projects will be more cautious after this story.

If you’re being berated by multiple people as to your speed of delivery, then it is not unexpected for them to be convinced that they are somehow the problem, and transfer the project to whoever they feel at the time is the best choice without thinking through their decisions.

However, knowing a person personally doesn’t necessarily solve the problem.

I used to work on an open source project a long time ago (under a pseudonym) that I do not wish to name here for reasons that’ll become clear shortly. The lead programmer had a co-maintainer who the lead seemed to have known quite well.

The co-maintainer constantly gaslit me, and later, other maintainers, belittled them, criticized them for the smallest of bugs etc. (and not in a Linus Torvalds way, where the rants are educational if you remove the insults) until they left; and was egged on by the lead maintainer as they agreed with the technical substance of these arguments.

Many years later, the co-maintainer attempted a hostile takeover of the project, which did not go as expected, and soon after, multiple private correspondences with other people became public where it became clear that the co-maintainer always wanted to do this, and gaslighting other maintainers was just part of this goal. All of this, despite the fact that the two of them knew each other.

Re: What we know about the xz Utils backdoor that almost infected the world

#27
post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

libsystemd is too juicy of a target, especially with the code reuse that does not appear to take into account these attack vectors.

Perhaps any reuse of libraries in sensitive areas like libsystemd should require a separate copy and more rigorous review? This would allow things like libxv to be 'reused', but the 'safe' versions would require a separate codebase that gets audited updates from the mainline.

Re: What we know about the xz Utils backdoor that almost infected the world

#29
post #11

I’m guessing the original maintainer of xz handed responsibilities to Jia Tan without ever seeing him/her or at least sharing a phone call. Is that common to only communicate only through email/github? I guess some maintainers of open source projects will be more cautious after this story.

What difference would a phone call have made? How would it have added any confidence as to the intentions of the person whatsoever?

Re: What we know about the xz Utils backdoor that almost infected the world

#30
post #4

Are we ever going to figure out who Jia Tan is?

If it was state-sponsored (considering the timeline, that's a real possibility), then "Jia Tan" could actually be a collection of folks, working for the same team.

I think 'Jia Tan' is one person who's committing the changes, based on the language used in the commits. Whether those changes came from a group will never be known.
Post reply on HN