Yeah I think if there's anything this results in it will be that non-developer corporate people (hey Legal department) will realize that the fact that open source contributions are peer reviewed doesn't mean bad faith code cannot be merged.

... and that it doesn't matter if you're a paying Red Hat customer. You'll still end up with it in your product.

I do wonder if this will create some anti open source backlash though. It's of course not rational, but when has such decisions ever been.

I have strong feels that it's not just open source that suffers from this.

At least with open source, one can look at the source.

in my mind, I imagine that there are probably some others in use right now...

and it is a LOT worst in closed source software, where no one can analise it thoroughly.
IOT products come to mind easily

> But we are Open Source which allows everyone to dig, check, read code and investigate.

And *this* is the main difference between companies like Microsoft, Apple etc., and open source software on the other hand. In this case, you can see the exploit, you can find out who inserted it and you can check all of the history of the project, down to when those people first showed up.

If there's something like this in closed source, you wouldn't know. It would never be shown in public.

I guess the only way to fix something like this is to completely flip around how permissions work from the current denylist approach to an allowlist approach.

Something that, from my understanding, WASI is doing.

But the current model of doing things is so ingrained in our operating systems, programming languages, ABIs and, to some extent maybe even hardware, that it seems like an impossible thing to do retroactively.

Even then, this particular attack was carefully designed to get glossed over by code auditors!

I personally looked at XZ somewhat recently, and while I can't tell you whether I audited a malicious version...

And yes I was studying the tarballs!

My favorite part of all of this is people going on about "resilience" and achieving it by building another version of everything (that also has to be compatible, otherwise how will people make use of it?):

"Then build in resilience. Defense in depth, and diversity — not a monoculture. OpenSSH will always be a target because it is so widespread, and the OpenBSD developers are doing great work and the target was upstream of them because of this. But we need a diverse ecosystem with multiple strong solutions, and as an organization you need second suppliers for critical software." (https://www.docker.com/blog/openssh-and-xz-liblzma/)

Does this mean we can expect another group to write a curl compatible library in Rust now so we have some resilience and diversity? (this is sarcasm, I feel some people might take this seriously. It is not serious, it is sarcasm).

OpenSSH and XZ/liblzma: A nation-state attack was thwarted, what did we learn? | Docker

Docker CTO Justin Cormack looks at what we can learn from malicious code in upstream tarballs of xz targeted at a subset of OpenSSH servers. "It is hard to overstate how lucky we were here, as there are no tools that will detect this vulnerability."

^Docker

Precompiled code would be the one thing that is likely to be seen again or in other existing attacks, I would like to see a GCC that puts specific magic in all object files and a linker or post install check that looks for it consistently.

An advanced attack can put the mark in new exploits but it gets harder to hide.

I guess this fits under dig, check, investigate.

What we can do is at least fingerprint the methodology used by this same threat actor to discover if there were any other very similar attempts.

It's likely there will be common elements in how they reached out to various open source projects which were very common dependencies.

This won't catch all cases, but it could catch some.