Live data from Hacker News

Timeline of the xz open source attack

research.swtch.com

151–160 of 482 posts

Re: Timeline of the xz open source attack

#151
post #83

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 makes Rich Hickey’s „Open Source Is Not About You” [0] particularly poignant. As a hobbyist developer/maintainer of open source projects, I strive to remember that this is my gift to the world, and it comes with no strings attached. If people have any expectations about the software, it’s for them to manage; if they depend on it somehow, it’s their responsibility to ensure timely resolution of issues. None of this…

This is why I find some disclaimers in some open source projects quite superfiscial, that the software is provided as is without any warranty. Of course it is, this should be the obvious default.

If there is a law that would entitle a user to more, it is a bug in legislation that needs urgent fixing.

Re: Timeline of the xz open source attack

#152

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.

All things considered I'm not sure that'd be such a good thing How many security issues spring from outdated packages vs packages updated too hastily?

On top of that:

A newly-introduced security issue tends to have very limited exploitability, because it's valuable, not-yet well understood, and public exploits are yet to be developed.

Compare to that a similar vulnerability in an older package: chances are that everything about it has been learned and is publicly known. Exploits have become a commodity and are now part of every offensive security distro on the planet. If you run that vulnerable version, there's a real risk that a non-targeted campaign will randomly bite you.

Re: Timeline of the xz open source attack

#153

Earlier quoted context omitted.

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…

> allow for developer being shouted down or exploited much more easily

No is an answer. And blocking people should be a thing.

Personally I do not publish anything anymore which is not "non-commercial only" as a result of demands, you can do it yourself if you want to make money off it (or if you demand things for that matter). Fortunately my online stuff isn't used much but even then it's possible to get "requests".

Re: Timeline of the xz open source attack

#154
post #121
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…

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…

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

The work was not being done "for giant corps"; it was being done for everyone, and giant corps just happen to be a part of "everyone", together with small corps, individual people, government, and so on.

> You have the right to be paid for your time. It's valuable.

When you think of free software contributions as "volunteer labor" instead of just a hobby, it makes more sense. Yes, my time is valuable; when I'm working on free software, I'm choosing to use this valuable time to contribute to the whole world, without asking for anything in return.

Re: Timeline of the xz open source attack

#155
post #137

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.

That would be true if you could ban the person from using new emails, but I don't think that's true when the thread if rife with sock puppet accounts. You ban the first rude email account, then there will be 2 new accounts complaining about both the lack of commits and the "heavy-handed mailing-list moderation" stifling differing views.

Absolutely right. Considering there is a whole cottage industry about asshole replies from Linus Torvalds on linux mailing lists.

For lesser/individual maintainers there is no way to survive this kind of mob attack. Corporate maintainers may be able to manage as it could be considered just as paid job and there are worse ways to make money.

Re: Timeline of the xz open source attack

#156

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

Re: Timeline of the xz open source attack

#157
post #76

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

It's not a perfect solution, but I think Big Companies could have a role to play here. Some kind of tenure/patronage system, where for every $1B a Big Company makes in profit, they employ one critical open source maintainer with a decent salary (like $200k or something). The job would only have two requirements: 1) don't make everyone so mad that everyone on the Internet asks for you to be fired, and 2) name a suitab…

> "It's not a perfect solution"

Is it a solution at all? Say Oracle offer Lasse Collin $200k for maintaining xz but he doesn't want to work for Oracle so he refuses, then what? Amazon offer Lasse $200k but they require fulltime work on other open source packages which he isn't experienced with or interested in, so he refuses, then what? Google employ someone else for $200k but they can't force Lasse Collin to hand over commit rights to xz to Google, or force him to work with a fulltime Google employee pestering with many constant changes trying to justify their job, and they can't force Debian to accept a new Google fork of xz, so then what? And NetFlix, Microsoft, Facebook, Uber, they can't all employ an xz maintainer, xz doesn't need that many people, but if they just employ 'open source maintainers' scattering their attention over all kinds of random projects they have no prior experience with, how would they catch this kind of subtle multi-pronged long-term attack on some low-attention, slow moving, project?

Google already employ a very capable security team who find issues in all kinds of projects and publicise them, they didn't find this one. Is it likely this attack could have made its way into ChromeOS and Android if it wasn't noticed now, or would Google have noticed it?

> "1) don't make everyone so mad that everyone on the Internet asks for you to be fired"

So it's a sinecure position, doing nothing is the safest thing?

> "and 2) name a suitable replacement when you're ready to move on"

How could Lasse Collin have named a more suitable replacement than someone who seemed technically capable, interested in the project, and motivated to work on some of the boring details like the build system and tests and didn't seem to be doing it for the hype of saying "I improved compression by 10%" for their resume? Are they needing to be skilled in hiring and recruitment now?

Re: Timeline of the xz open source attack

#158
post #88

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…

Look how brilliantly they selected their target project: (1) xz and the lib are widely used in the wild including linux kernel, systemd, openSSH; (2) single maintainer, low rate of maintenance; (3) the original maintainer has other problems in his life distracting them from paying closer attention to the project. I am wondering how many other OSS projects look similar and can be targeted in similar ways?

Many.

We're in a tech slowdown right now. There are people who got used to a certain lifestyle who now have "seeking work" on their LinkedIn profiles, and who have property taxes in arrears that are listed in county newspapers-of-record. If you're an intelligence operative in the Silicon Valley area, these guys should be easy pickings. An envelope full of cash to make some financial problems go away in exchange for a few commits on the FOSS projects they contribute to or maintain.

Re: Timeline of the xz open source attack

#159

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…

The Jigar Kumar nudges are so incredibly rude. I would have banned the account, but perhaps they contributed something positive as well that isn't mentioned. I wonder if it would be possible to crowdsource FOSS mailing list moderation.

>I wonder if it would be possible to crowdsource FOSS mailing list moderation.

I think this could be a genuine use of an AI: to go through all of the shit, and have it summarized in a fashion that the user wants: distant and objective, friendly, etc. It could provide an assessment on the general tone, aggregate the differently phrased requests, many things like that.

Crowdsourcing would works best with the reddit / hacker news model I feel, where discussion happens in tree styled threads, and users can react to messages in ways that are not text, but something meta, like a vote or a reaction indicating tone.

Both of these have significant downsides, but significant upsides too. People pick the mailing list in a similar way.

Re: Timeline of the xz open source attack

#160
post #76

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

It's not a perfect solution, but I think Big Companies could have a role to play here. Some kind of tenure/patronage system, where for every $1B a Big Company makes in profit, they employ one critical open source maintainer with a decent salary (like $200k or something). The job would only have two requirements: 1) don't make everyone so mad that everyone on the Internet asks for you to be fired, and 2) name a suitab…

I think the best solution would be governments forcing companies to secure the entire pipeline and setting up a non profit that does this for open source packages. Have security researchers work for a non profit and force companies that use software from some guy in Nebraska to pay into the non profit (could be in the form of labor) to get the code checked and certified.

The guy in Nebraska is still not getting anything but will also not have the stress of becoming one of the main characters/victims in a huge attack.

Post reply on HN