The abusive behavior that was being used to manipulate Lasse Collin into bringing on more maintainers for #xz went unnoticed because abusive behavior in Open Source communities is so pervasive. In context, we can clearly see it was part of an orchestrated operation. Out of context, it looks like just another asshole complaining about stuff they have no right to complain about. https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/
Again the FOSS world has proven to be vigilant and proactive in finding bugs and backdoors, IMHO. The level of transparency is stellar, especially compared to proprietary software companies. What the FOSS world has accomplished in 24 hours after detection of the backdoor code in #xz deserves a moment of humbleness. Instead we have flamewars and armchair experts shouting that we must change everything NOW. Which would introduce even more risks. Progress is made iteratively. Learn, adapt, repeat.
Ça fait deux jours que je suis fasciné par ce qui se passe dans le monde de la sécurité informatique, autour de la backdoor XZ. Je vais essayer de vous l'expliquer, ça va être technique, mais c'est important.
Pour Internet, c'est l'équivalent d'un gros astéroïde qui serait passé à 5000km de la Terre. Pas d'impact, pas de dégâts directs, mais on aurait pu tous y passer et personne ne l'a vu venir.
Je vais chercher à vulgariser un maximum, tout en donnant des liens vers les sources directes, qui sont souvent très techniques et en anglais. Ça va être un peu long, mais c'est passionnant.
Three years ago, #FDroid had a similar kind of attempt as the #xz#backdoor. A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn't found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a #SQLinjection#vuln. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think its relevant now
An incredibly technically complex #backdoor in xz (potentially also in libarchive and elsewhere) was just discovered. This backdoor has been quietly implemented over years, with the assistance of a wide array of subtly interconnected accounts:
I think the #xz incident is teaching us that our infrastructure is dangerously fragile in the face of well-organized/funded attackers. The response isn’t “try harder” or “donate to your OSS project”, it needs to be institutional, professional, and at scale.
You know you could just... give... the money... to projects that need it. Like software libraries that ARE IN EVERYTHING.
No grants. Don't make tech nerds write grants.
Don't make the tech nerds hire grant nerds to write grants.
FFS don't fund research into this problem with a budget of double what it would take to SOLVE THE PROBLEM for a significant number of open source projects with code that is, again, IN EVERYTHING.
During the 2013-2018 boom when tech workers as a class had maximum leverage, used some of the energy organizing broad tech unions and guilds instead of negotiating for fuck-you money and pulling up the ladder by telling other trades to “learn 2 code noobs”
craft broadly populist multi-union legislation to raise taxes for “infra and natsec basic income fund”, for a living stipend to infra workers: railroad, steelworkers, electricians, OSS maintainers
If #xz were a Go or Rust dependency, you wouldn’t have a single copy of xz library on your system, but many, #xzbackdoor hidden in every executable that uses it. Distros would have to rebuild all packages using that lib (not just the lib itself), which could take days or weeks, and users would have to update them all, downloading tens or hundreds of megabytes.
If you install binaries directly from vendors/devs, it’s even worse – you wouldn’t even know which ones are affected and you’d (1/3)
There simply is no established or easy way to detect backdoors done the #xz way. We give powers and trust to maintainers because that is the development model.
Anyone suggesting there is an easy fix has not understood the issues at hand.
But we are Open Source which allows everyone to dig, check, read code and investigate.
Meanwhile, #Debian is considering rolling #xz back not only to the point before the backdoor was added, but to where the person who wrote the backdoor hadn't contributed any code to xz yet.
Which means considering creating patches to fix ABI breakage such a rollback would cause.
Please do not advise people to run xz --version or similar to check whether they're affected or not.
Right now, as far as I know, the analysis of the obfuscated malware is far from complete. There may be other triggers. There may be malware in older versions, because the attacker had commit access for years.
By running xz and asking it for its version, you're running what could be more malware.
Instead, ask the system's package manager which version of xz is currently installed.
Lasse Collin has posted an update on his plans for #xz and clearing up what happened: https://tukaani.org/xz-backdoor/ I hope he’s met with all the support and patience he needs.
one thing I'm sure about "Jia Tan" is that they had extensive prior experience with open source development. Everything they write in #xz commits is pitch-perfect. This is not their first rodeo.
Kind of makes you wonder what projects they contributed to while learning all that and under what names.
It's important to note how critical it was caught now: all the commercial distributions are making releases over the next 12-18 months: Red Hat with RHEL 10 in May 2025, SUSE with SLE 16 in fall 2025, and Canonical with Ubuntu 24.04 in April. It was key to infect their upstreams (Fedora, openSUSE, Debian) now.
That’s not my name! Practical problems in real name policies.
Once in a while, big companies suggest that the answer to abuse is to ban anonymity and institute a Real Names policy. This time, it is Google's turn. They think that critical software should only be authored by people with "real names".