Live data from Hacker News

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

arstechnica.com

11–20 of 336 posts

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

#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.

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

#13
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.

That’s basically how it is right now. Millions of companies freeloading off the work of unpaid open source developers. Unsurprisingly they sometimes leave and it causes problems.

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

#16
post #4

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

It sounds unlikely that he was an individual working on his own. So if the organisation he worked for has another Snowden, yes. (I am not saying it is necessarily the same organization, there are at least 4 obvious candidates and it could be a more surprising one.)

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

#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 problem. If you have this type of stuff in your repository also have an automatic test that checks that nobody tampered with it (it will also keep you from having stale autogenerated files in your repository).

3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.

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.

5. In general there's a culture that code reuse is always good, that depending on large libraries for small amounts of functionality is good. This is not true, dependencies are maintenance burden and a security risk, this needs to be weighted against the functionality they bring in.

6. Distro maintainers applying substantial patches to packages is a problem, it creates widely used de facto forks for libraries and applications that do not have real maintainers looking at them.

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.

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

Post reply on HN