Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

Post reply on HN
Print view View original

351–360 of 482 posts

Re: Timeline of the xz open source attack

#351

Post by lukaslalinsky »

michaelt wrote: post #165
lukaslalinsky wrote: post #63

Earlier quoted context omitted.

It does help on the social/psychological side. If you, as an open source project maintainer, have a policy that such rudeness is not acceptable, you are much less likely to become a successful victim of a social attack like this.

It's entirely possible for an evildoer to make someone feel bad while remaining completely polite. First send a message to the mailing list as "Alice" providing a detailed bug report for a real bug, and a flawless patch to fix it. Then you reply to the mailing list as "Bob" agreeing that it's a bug, thanking "Alice" for the patch and the time she spent producing such a detailed bug report, then explaining that unfort…

As someone else said in this thread, scammers are often rude, because it makes people act fast, polite responses give them time to think. Of course, people are very easily manipulated. But by completely rejecting rudeness and having the mindset to not let others put pressure on me, you will improve the odds by a lot.

Re: Timeline of the xz open source attack

#352

Post by cryptonector »

psanford wrote: post #193

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

What's inscrutable code? Was it m4 or sh or the combination of the two?

Who will pay for all the rewriting you want done? Or even just for the new frameworks that are "scrutable"? How do we guarantee that the result is not inscrutable to you or others?

There is so much knee-jerking in this xz debacle.

(And I say this / ask these questions with no love for autoconf/m4/sh.)

Re: Timeline of the xz open source attack

#353

Post by cryptonector »

kibwen wrote: post #197
psanford wrote: post #193

One 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's a great first step, but ready your pitchforks for this next take, because the next step is to completely eliminate Turing-complete languages and arbitrary I/O access from standard build systems. 99.9% of all projects have the capability to be built with trivial declarative rulesets.

This is a better take. Though I'm sure people can obfuscate in source code just as much as in build configuration code.

Re: Timeline of the xz open source attack

#354

Post by cryptonector »

userbinator wrote: post #86

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.

That's a double-edged sword. What happens when you need to upgrade in order to get vulnerability fixes?

Re: Timeline of the xz open source attack

#355

Post by cryptonector »

saghm wrote: post #272
coldpie wrote: post #96

Earlier quoted context omitted.

Even if the security outcome is the same, I would still count people being kind and helpful online instead of rude as an improvement.

As always, there's an xkcd for that https://xkcd.com/810/

That's amazing.

Re: Timeline of the xz open source attack

#356

Post by djmips »

publius_0xf3 wrote: post #275
sebstefan wrote: post #69

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.

I want to caution against taking a good thing too far. There's a certain kind of talented person who is all too conscious of their abilities and is arrogant, irascible, and demanding as a result. Linus Torvalds, Steve Jobs, Casey Muratori come to mind. Much as we might want these characters to be kinder, their irascibility is inseparable from their more admirable qualities. Sometimes good things, even the best things…

That's a tough one - It's hard to fully disagree but in my experience you can have all the benefits without the poison. Accepting the poison just because of the benefits is kind of just giving up. I don't feel like the your hypothesis that the two are irrevocably linked holds up under examination.

Re: Timeline of the xz open source attack

#357

Post by [deleted] »

1024core wrote: post #309

I am reminded of the infamous Sendmail worm from 1989(?). If this compromised OpenSSHd had become the default across millions of systems all over the world, could a worm-like thing have brought a major chunk of the Internet down? Imagine millions of servers suddenly stuck in a boot-loop, refusing to boot. And all because one owner of a library had some mental health issues. We should not have such SPOFs.

[deleted]

Re: Timeline of the xz open source attack

#358

Post by jethro_tell »

nrawe wrote: post #195
jethro_tell wrote: post #172

Earlier quoted context omitted.

You don't think every nation state has people inside private software shops? Especially big tech? Look at stuff getting signed with MS keys, hardware vendors with possible backdoors. Social engineering is social engineering and it can happen anywhere no matter the profit motivation or lack there of. Money interest in software won't save you any more than Foss.

It'd be naive to assume that nation state actors are not trying to penetrate the supply chain at all levels, as it just takes a single weak link in the chain. That weak link could be behind corporate doors or in the open. The main issue is that this attack shows how a relatively unknown component, as part of a much larger and more critical infrastructure, is susceptible to pressure as a result of "this is a hobby pro…

I think googles program to hire security researchers was a minor step in the right direction, but it would behoove big tech and or various governments, to do the same thing these state intelligence actors are doing, and take a look at all of these projects that touch core infra and investigate the maintainers and their vulnerability.

I would bet that some of these projects like xz would show enormousness benefits from one paid person working on it 1/4 time, leaving room for a couple more projects per dev. Additionally, a couple places providing relatively minor grants would probably help a dev buy back some of their time so the can work on their project some other time then 'after the kids are in bed'

Re: Timeline of the xz open source attack

#359

Post by cryptonector »

lenerdenator wrote: post #156
lukaslalinsky wrote: post #24

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 feel for Lasse. It's time for more of the big vendors who use these projects in their offerings to step up and give people running these small projects more resources and structure. $20k to have maintainers for each project actually meet twice a year at a conference is chump change for the biggest vendors, especially when compared against the cost of the audits they'll now be doing on everything Jia Tan and Co. tou…

As an OSS maintainer, $20k wouldn't help me enough unless I was retired. The issue is not money (or not just money), but time. If a maintainer has a full-time job, they may not have time, and developers/maintainers tend to have full-time jobs, so...

Now maybe one could build a career out of OSS maintainerships, with work/time funded by lots of donations much smaller than a salary but amounting to a salary.

Re: Timeline of the xz open source attack

#360

Post by duped »

kibwen wrote: post #197
psanford wrote: post #193

One 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's a great first step, but ready your pitchforks for this next take, because the next step is to completely eliminate Turing-complete languages and arbitrary I/O access from standard build systems. 99.9% of all projects have the capability to be built with trivial declarative rulesets.

What would that accomplish? It certainly wouldn't have stopped this attack.

> 99.9% of all projects have the capability to be built with trivial declarative rulesets.

Only if you forbid bootstrapping, which all projects ultimately rely on at some point in their supply chain.

Post reply on HN