Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

331–340 of 482 posts

Re: Timeline of the xz open source attack

#331

I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.

I'm kinda the opposite. Way too many times I've seen "upgrades" actively remove things I liked and add things I hate. I hold off on letting mobile apps update because they almost always get worse, not better.

Re: Timeline of the xz open source attack

#332

Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.

The attackers will leverage any culture that helps them accomplish their goals. If being rude and pushy doesn’t work, the next round will be kind and helpful. Don’t read too much into the cultural techniques used, because the cultural techniques will mirror the culture at the time.

Agree. I think a more core issue here is that only 1 person needed to be convinced in order to push malware into xz

Re: Timeline of the xz open source attack

#333

Never allow yourself to be bullied or pressured into action. As a maintainer, the more a contributor or user nags, the less likely I am to oblige.

True, but a determined adversary like JiaTan/Jugar has an ace up their sleeve: they are good enough, and patient enough, to be able to fork the base project, spend a year or two making it better than the original (releasing the head of steam built up from legitimate requests that the old, overworked maintainer never got too, building goodwill in the process) and then convincing the distros to pick up their fork instead of the older original. At which point it really is game over.

Re: Timeline of the xz open source attack

#334
post #252

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

When your programmatic build steps are isolated in plugins, then you can treat them like independent projects and apply your standard development practices like code review and unit tests to those plugins. Whereas when you stuff programmatic build steps into scripts that are bundled into existing projects, it's harder to make sure that your normal processes for assuring code quality get applied to those pieces of acc…

My standard development practices like code review and unit tests do not scale to review and test every dependency of every dependency of my projects. Even at company-wide scale.

Re: Timeline of the xz open source attack

#335

Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.

[dead]

Re: Timeline of the xz open source attack

#336

Earlier quoted context omitted.

The Jia Tan character was never rude. If you make rudeness the thing that throws a red flag, then ‘nice’ fake accounts will bubble up to do the pressuring.

Jia Tan wasn't rude, but the original maintainer Laser Collin probably wouldn't have been as burned out and willing to give responsibility to them if the community wasn't as rude and demanding of someone doing free work for them. I think we need to start paying more of these open source maintainers and have some staff/volunteers that can help them manage their git hub issue volume.

The article covers that those rude accounts may have been sybils of the attacker to create pressure. It's effectively good cop/bad cop for open source.

Re: Timeline of the xz open source attack

#337
post #170

Earlier quoted context omitted.

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.

Fair enough - I agree that sophistication inspires the presumption, but it's still just that (not that you said otherwise - just emphasizing).

Anyway, I've yet to hear of anything in the xz work beyond the ability of 1-3 skilled black hats with a lot of post-COVID time on their hands. The NSA ensuring the Intel ME/AMT could be turned off seems another level of sophistication entirely, for example { a "higher pinnacle" in your nice phrasing :-) }.

In terms of sheer numbers, my impression is that the vast majority of attacks blocked at almost every sophistication level are more "criminals" than "states". Admittedly, that may partly be states just acquiring ability to act surgically rather than launching big compromise initiatives like botnets (or otherwise states going undetected). I'm sure it's hard to know.

Maybe we're just in a sad era of increasing attack sophistication measured in "Kilo-Sophistic-meters"? The AntiVirus industry has been having a boom lately.

It's probably already been mentioned many times, but besides economic & geopolitical incentives, maybe the attacker(s) was a hard core `systemd` or IBM/RedHat hater or one of the people who supposedly issued death threats to Lennart Poettering now at Microsoft or even an open source hater burnt out or wanting to burn the world down like The Joker in Batman. In light of that, Russ' Setting The Stage Prelude could perhaps profitably add the introduction of that lib dependency into `systemd` and also various distros defaulting to `systemd`.

Anyway, premature conclusions are to be cautioned against over & over. That's all I was trying to do. { And I'm not claiming you were concluding anything - you seem pretty open-minded about it all. I was always just amplifying parent comments. I absolutely agree long games "feel" more State Actor - part of what I meant by "vibe", but to quote the detective in V For Vendetta - "it's just a feeling". To Old People, 2 years famously doesn't seem as long as to a 25- or 15-year old. ;-) It's actually short on the 5+ year Linux distro maintenance time scales. }

Re: Timeline of the xz open source attack

#339
post #142
post #125

Earlier quoted context omitted.

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.

I'll bet many of them simply wouldn't want to.

Re: Timeline of the xz open source attack

#340
post #106

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…

I’ve given semi-popular projects that I no longer had the bandwidth to maintain to random people who bothered to email, no pressuring needed. While those projects are probably four to five magnitudes less important than xz, still thousands of people would be affected if the random dude who emailed was malicious. What should I have done? Let the projects languish? Guess I’ll still take the chance in the future.

If it's open source they can just fork it, and if you're no longer maintain yours you can put a link over to their fork. (Or any other active forks). It's still on the user to vet new forms.
Post reply on HN