I wonder if netflix will make a movie from this story, if you read the timeline it really sounds like a well written thriller.
Timeline of the xz open source attack
141–150 of 482 posts
Re: Timeline of the xz open source attack
#142Earlier quoted context omitted.
While "open source" fundamentally doesn't work that way, the point here is about maintainers , not regular contributors. Identity of new maintainers must be vetted (via in-person meetups and whatever other mechanisms) by other "trusted" maintainers whose identities are "verified". I realize, it's a hard problem. (And, thanks for the link to the "Know, Prevent, Fix" post.) PS: FWIW, I "win my bread" by working for a c…
I’ve worked with a few very talented pseudonymous developers on the Internet over the years. I can’t think of any way to vet their identities while maintaining their anonymity (well, it’s basically impossible by definition), plus if you’re talking about in-person meetups, traveling from, say, Asia to North America isn’t cheap and there could be visa issues. The distinction between maintainers and non-maintainers isn’…
And there are other reasons some people might not want to travel outside their nearby region. For instance, they might be taking care of an elderly relative. Or they might be the elderly relative, with travel counter-indicated for health reasons.
Re: Timeline of the xz open source attack
#143A "good" side effect of this for OSS maintainers going on, is that now any time an entitled user starts being too pushy or too... well, entitled , they can be given a canned response: Are you trying to pull an xz attack on me?
Ah, the old "undercover cops can't lie about not being a cop, just ask them" technique.
Re: Timeline of the xz open source attack
#144"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…
This event should be a wake-up call to businesses everywhere: It's not just a small number of "core" FOSS projects that need their support (funding and assistance!). Before this event who was thinking about a compression library when considering the security of their FOSS dependencies? The scope of "what FOSS needs to be supported and well-funded" just increased by an order of magnitude.
The demand for more assistance here is the angle that was played in social engineering, specifically the demand to acquire more maintainers due to workload. Especially if such support would take the form like providing source archives with manipulated build scripts that are rarely checked by third parties.
There is also a problem of badly behaving industry that tries to take control of "hobby projects". Speaking of which, these "hobby"-projects often have much better code than many, many industry codebases.
I think FOSS overall still lessens the risk. It got more risky since it has been integrated in social media since these often allow for developer being shouted down or exploited much more easily.
Re: Timeline of the xz open source attack
#145This seems very difficult to defend against. What is a project with a single burnt-out committer to do?
lcamtuf's two posts argue that this may simply not be an open-source maintainer's job to defend against. ("The maintainers of libcolorpicker.so can’t be the only thing that stands between your critical infrastructure and Russian or Chinese intelligence services. Spies are stopped by spies.") That doesn't mean we shouldn't try to help burnt out committers, but the problem seems very hard. As lcamtuf also says, many th…
Re: Timeline of the xz open source attack
#146A service that measured "credibility" or "activity" of a username/email could be really useful here. At least, it would be a leading indicator that something _might_ be up. In particular the aside here about the email addresses are suspect: https://research.swtch.com/xz-timeline#jia_tan_becomes_maint... would be useful info for Lasse Collins before taking the pressure campaign seriously.
Re: Timeline of the xz open source attack
#147What makes you think that the accounts were not compromised only recently?
Re: Timeline of the xz open source attack
#148The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into…
It's bizzare enough as it is to start asking questions to confirm that "mental issue" had natural cause.
Re: Timeline of the xz open source attack
#149This seems very difficult to defend against. What is a project with a single burnt-out committer to do?
In this instance, noticing the people emailing to pressure you have fake looking names that start with adjacent letters and the same domain name.
Be more paranoid.
Re: Timeline of the xz open source attack
#150Earlier quoted context omitted.
That's just the nature of free software- you have to either trust the maintainer or do it yourself. There is not really a way around it. - Corporate maintainers are great until they enshittify things in the pursuit of profit (see Oracle) - Nonprofits are probably the best but can go the same route as corps (see Mozilla) - Hobbyists are great until they burnout (see xz)
I think the level of complexity is the problem. A bad actor can be embedded in any of the above contexts: corp, non-profit, FOSS hobbyist. It doesn’t matter. The question is: when software is so complex that no one knows what 99.9% of the code in their own stack, on their own machine, does (which is the truth for everyone here including me), how do you detect ‘bad action’?