What we know about the xz Utils backdoor that almost infected the world
11–20 of 336 posts
Re: What we know about the xz Utils backdoor that almost infected the world
#12I didn't realize it was a Microsoft engineer that works on Azure Postgres that found the issue. Thanks, Microsoft, I like Azure now.
Re: What we know about the xz Utils backdoor that almost infected the world
#13I’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
#14This meme was a mistake.
Re: What we know about the xz Utils backdoor that almost infected the world
#15Re: What we know about the xz Utils backdoor that almost infected the world
#16Are we ever going to figure out who Jia Tan is?
Re: What we know about the xz Utils backdoor that almost infected the world
#17Are we ever going to figure out who Jia Tan is?
Re: What we know about the xz Utils backdoor that almost infected the world
#18Why does SSH use xz? Should it? Is it really that important?
Re: What we know about the xz Utils backdoor that almost infected the world
#191. 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.