Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

141–150 of 482 posts

Re: Timeline of the xz open source attack

#141
post #27

I wonder if netflix will make a movie from this story, if you read the timeline it really sounds like a well written thriller.

It does, but has there ever been a movie that successfully portrayed a compelling drama that takes place entirely on a computer monitor? It's hard to even imagine. It's why I think the novel is still relevant in our age because all the great stories that unfold on a screen can't be acted out on a sound stage.

Re: Timeline of the xz open source attack

#142
post #125

Earlier 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’…

> traveling from, say, Asia to North America isn’t cheap and there could be visa issues.

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

#143
post #62

A "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.

If you casually ask this while you can study (and preferably record!) the person's posture and they react in real-time then you can apply interrogation technique which CIA et al use.

Re: Timeline of the xz open source attack

#144
post #78

"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.

This would of course be nice since the fact that so much of our infrastructure is based on the work of people sharing it openly, a practice heavily in contrast to industry behavior, is sadly still a little known fact outside of software development.

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

#145
post #40

This 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…

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...

Re: Timeline of the xz open source attack

#146

A 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.

What about just using 'web of trust', for example with GPG? If the user's key is signed by people that met up with the actual person, it would be much harder to make fake identities.

Re: Timeline of the xz open source attack

#147
post #71

What makes you think that the accounts were not compromised only recently?

If the account was compromised only recently the real co-maintainer would have done everything to warn the maintainer. If you're maintaining some core piece of infrastructure and your account gets compromised it would be trivial to let at least someone know you're not the one pushing these commits.

Re: Timeline of the xz open source attack

#148

The 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.

Your experiences may differ, but I'd say pretty much anyone who lived through the past few years has reason enough to pay careful attention to their mental health.

Re: Timeline of the xz open source attack

#149

This seems very difficult to defend against. What is a project with a single burnt-out committer to do?

Check the GitHub profile of anybody that commits. Is there a photo of the person? Can you see a commit history and repos that help validate who they seem to be.

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

#150
post #101

Earlier 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’?

The level of complexity involved in making sure that electrical plants work, that water gets to your home, that planes don't crash into each other, that food gets from the ground to a supermarket shelf, etc, is unfathomable and no single person knows how all of it works. Code is not some unique part of human infrastructure in this aspect. We specialize and rely on the fact that by and large, people want things to work and as long as the incentives align people won't do destructive things. There are millions of people acting in concert to keep the modern world working, every second of every day, and it is amazing that more crap isn't constantly going disastrously wrong and that when it does when are surprised.
Post reply on HN