What's crazy to me about how we've set up computers to do things, is that xz itself is a pure function, but somehow there's all of this shit that has to happen to just use a pure function! It's just bytes in and bytes out, but we have an astoundingly complex build system and runtime linking system which somehow allows this pure function to run arbitrary commands on a system.
Timeline of the xz open source attack
261–270 of 482 posts
Re: Timeline of the xz open source attack
#262Earlier quoted context omitted.
Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left. There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverag…
> Findbugs, code coverage, source code generation,... For the purpose of this conversation we mostly just care about the use case of someone grabbing the code and wanting to use it in their own project. For this use case, dev tools like findbugs and code coverage can be ignored, so it would suffice to have a version of the build system with plugins completely disabled. Code generation is the thornier one, and we can…
The xz debacle happened partiallybecause the generated autoconf code was provided. Checking in generated code is not that much better. It's a bit more visible, but not much people will spend their limited time to validate it, as it's not worth it for generated code. xz also had checked in inscrutable test files, and nobody could know it was encrypted malware.
I'm not a fan of generated code. It tends to cause misery, being in a no mans land between code and not-code. But it is usefull sometimes, e.g rust generating an API from the opengl XML specs.
Sandboxing seems the least worst option, but it will still be uninspected half code that one day ends up in production.
Re: Timeline of the xz open source attack
#263Earlier quoted context omitted.
Why the assumption this is a Russian or Chinese intelligence service? Western governments aren't above this sort of conduct: https://www.mail-archive.com/cryptography@metzdowd.com/msg12...
Why are people assuming it's any intelligence service/state actor? With cryptocurrency valuations, it would seem like remote rooting gajillions of machines would be highly incentivized for a private person/collective. Not to mention other financial incentives. Our digital infrastructure secures enormous value much of which can be pilfered anonymously. I admit, the op has a "professional/polished vibe" to me as well,…
people often assume state actors are the pinnacle of sophistication, and especially long games. (Also notably Chinese culture is very attuned / trained for long games, relative to American impatience). This was a sophisticated attack, therefore presumption.
Re: Timeline of the xz open source attack
#264"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…
Sorta but flawed relevant xkcd: https://xkcd.com/2347/ I don't see how this is any strongly different than some unappreciated skill worker in a corporation. Its interesting the double standard we have for FOSS. Meanwhile in the commercial world, supply chain attacks are commonplace and barely solicit headlines. Yes, FOSS needs to be able to address these kinds of attacks, but the world runs on the efforts of the low-…
This is one of the sanest comments I've ever seen describing what FOSS actually is. I think you nailed it when you said:
> We can't just say "Oh FOSS is better than much closed software" when things are good, then immaturely reply "its just a dumb hobby, you're dumb for trusting me," when things go south.
It's weird. There are the explicit expectations of FOSS (mostly just licenses, which say very little), and the implicit expectations (everything else).
It's anarchic and ad hoc in a way that leaves the question of "what are we actually doing with this project(s)" up for all kinds of situational interpretation, as you noted. This is bad, because this ambiguity leads to conflict when the various actors are forced to reveal their expectations, and in doing so show that their expectations are actually quite divergent (i.e., "this is my fun hobby project!" vs. "my company fails without this bugfix!" vs. "I thought this was a community project!" vs. "This project is for me and my company, I call the shots, you're welcome to look at the code, though").
It's a little bit like the companies that are like "we have a flat management hierarchy, no one really reports to anyone else". It's just not true. It's almost always used as a ruse to dupe a certain class of participant that isn't sophisticated enough to know that these kinds of implicit power hierarchies leave them at a disadvantage. There's always a structure, it's just whether that structure is explicit or not. This kind of wishy-washy refusal to codify project roles/importance in FOSS is not doing us any favors. In fact I think it prevents us from actively recognizing the "clean water" role that an enormous number of projects play.
There's real labor power here if we want it, but our continued desire to have FOSS be everything to everyone is choking it.
Re: Timeline of the xz open source attack
#265> It's also good to keep in mind that this is an unpaid hobby project. That's the root cause. At some point a corp/gov consortium needs to adopt key projects and hire out the maintainers and give them real power and flexibility, perhaps similar to the way a nation might nationalize key infrastructure. But this is against the core ethos at some level. Freedom and safety can be antagonistic.
> gov consortium
Personally I wouldnt trust a govt to not backdoor everything.
Re: Timeline of the xz open source attack
#266One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.
That would be an improvement for sure... but this is not fundamentally a technical problem. Reading the timeline, the root cause is pure social engineering. The technical details could be swapped out with anything. Sure there are aspects unique to xz that were exploited such as the test directory full of binaries, but that's just because they happened to be the easiest target to implement their changes in an obfuscat…
> Is the real problem here handing over substantial trust to an anonymous contributor?
Unless there's some practical way of comprehensively solving The Real Problem Here, it makes a lot of sense to consider all reasonable mitigations, technical, social or otherwise.
> If a person has more to lose than maintainership then would this have happened?
I guess that's one possible mitigation, but what exactly would that look like in practice? Good luck getting open source contributors to accept any kind of liability. Except for the JiaTans of the world, who will be the first to accept it since they will have already planned to be untouchable.
Re: Timeline of the xz open source attack
#267> Evan Boehs observes that Jigar Kumar and Dennis Ens both had nameNNN@mailhost email addresses This is the second time I've read this "observation", but this observation is just wrong? Jigar's email is "${name}${number}@${host}", yes, but Dennis's is just "${name}@${host}" — there's not a suffixed number. (There's a 3, but it's just a "leetcode" substitution for the E, i.e., it's semantically a letter.) (They could…
Where are the email addresses visible? I've also seen this a few times, but never the actual addresses.
eg "Hans Jansen" is
Re: Timeline of the xz open source attack
#268Two points I'd be interested in discussing. 1. It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way (and selected for their access). Why play the long game of let's find a lone package, w/ a tired maintainer, and then try to get in good with them vs. Let's survey all packages w/ a tired ma…
Regarding point 1: The timeline in the linked article describes some communications as "pressure emails." I've heard the theory, but haven't seen solid evidence, that the pressure emails weren't just regular impatience from outside devs, but actually part of the attack. To convince the primary maintainer into granting access to another party.
Re: Timeline of the xz open source attack
#269Earlier quoted context omitted.
Never understood why our industry seems unique in our willingness to do unpaid work for giant corps. Your compression library isn't saving the world, it's making it easier for amazon to save a few bucks. You have the right to be paid for your time. It's valuable. I enjoy coding too... but the only free coding I do is for myself. Use a proper license, charge for your time and stop killing yourself doing unpaid hobby p…
> why our industry seems unique in our willingness to do unpaid work for giant corps. Because it never starts that way. It scratches an itch, solves an interesting puzzle and people thank and praise the work. Deep down we all want to be useful, and it helps that it looks great on a résumé. After it's established the big corps come along, but the feeling of community usefulness remains. It's also why so many devs burn…
IMO this is exactly why. The payout comes later, if the project is successful.
Re: Timeline of the xz open source attack
#270> It's also good to keep in mind that this is an unpaid hobby project. That's the root cause. At some point a corp/gov consortium needs to adopt key projects and hire out the maintainers and give them real power and flexibility, perhaps similar to the way a nation might nationalize key infrastructure. But this is against the core ethos at some level. Freedom and safety can be antagonistic.
Avoid compromise with one simple trick: surrender to the attackers