what's really wild is that I bet state actors could just find and offer money to unscrupulous open source contributors instead of wasting years on infiltration.
I bet somebody like that has his DMs open right now and state actors just have to be brave enough to reach out.
heck, state actors, I bet the answer is right in front of your eye sacks.
to repeat, the ANSWER is in front of your EYE SACK...
If you have not read this paper, you probably should. I don’t have a particular comment but the parallels are obvious and you are probably going to be seeing a lot of experienced security people referencing it in discussions in the coming days
If your Linux installation has the "xz" utility installed make sure to update your system and keep an eye on things, it has had a security backdoor installed for a while:
So now that we all understand that thanklessly relying on free work of overworked maintainers is a problem, how about we put our money where our mouth is?
I think @AndresFreundTec needs a fat bonus check for saving our asses.
And Lasse Collin needs a lot of support, and probably a nice vacation.
I pledge $100, for starters.
Now how can we make sure to send the funds to the correct people?
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.
As expected, a lot of motivated but not well-informed or qualified people in the comments are adding fuel to a fire that is effectively under control and almost extinguished, so when you read that FAQ, please ignore most of the comments under it.
To everyone losing their shit over the xz/liblzma debacle: This is how Open Source is supposed to work: many eyes looking over work-in-progress to make sure it works as intended. Sometimes it’s reviewing source code commits and other times it’s looking over the behavior of pre-release software, noticing anomalous behavior and chasing down the commit that caused it. This is preciselywhy we have debian-testing and FreeBSD-Current. If anything this is validation that Open Source works #xz#liblzma
Has anyone tried checking #liblzma#xz against known symbols to see what mismatches? Any differences in these differences between 5.6.0 and 5.4.5 (I expect there should be)?
Is there concern for snaps or flatpaks? Checking my own stuff it looks like applications using bundled liblzma are running in the 5.2.* - 5.4.* versions, but if someone has a bleeding edge application running an affected version, what would the remediation be? Would uninstalling it be sufficient?
So, it appears the #Rust ecosystem may be hit by the #xz backdoor as well, since the #liblzma bundles xz 5.6.0 and they even had a major/breaking update within the last month specifically to upgrade to the now known-to-be-corrupted version.