Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

41–50 of 353 posts

Re: Xz: A microcosm of the interactions in open source projects

#41

Earlier quoted context omitted.

> Help in maintainship how? Pay.

To me it would make more sense to add more eyeballs looking at what gets committed. For example, in this case who would you pay? The new (co-)maintainer was compromised and it would not help to pay him. Thus, in order for payments to help one would need to have some assurance that the person getting paid is not compromised. The easiest way to have some level of such assurance seems to be to pay ones own employees. Th…

The new (co-)maintainer was compromised and it would not help to pay him

Depends upon your perspective.

Hacker: "Oh it was hilarious, you should have been there! They donated $1M to the project after I hacked the code, so I took the $1M too."

Re: Xz: A microcosm of the interactions in open source projects

#42
I agree that the maintainer doesn’t really owe anything to anyone. Including the so-called consumers on the issue tracker. Furthermore the consumers have no real power over the maintainer; since they aren’t doing anything for them they in turn have nothing to withhold from the maintainer. And they can’t bother the maintainer unless they decide to turn truly vile and evil by doxing and harassing the maintainer. Thus the complaints of these consumers can be completely tuned out.

It follows then that the maintainer can just log off. Because either you believe that the maintainer has some minimal obligation to the community (like a quarterly update about maintainership status or making a notice in the readme if you decide to abandon the project) or you don’t.

But sometimes in these discussions things get muddied because people claim that

1. The maintainer doesn’t owe anything to anyone whatever

2. But she’s a nice gal which means that she will triage some bugs and fix some bugs and explain to a few of the issue reporters that they haven’t encountered a bug they just haven’t installed the program so that PowerShell can find it and

What’s the groans moral angle, here? We’ve already established (1). But what ought the maintainer do for herself? That’s also a moral problem. Are you willing to say that the maintainer ought to log off if they are experiencing burnout? (Again: this is about the moral obligations that the maintainer has to herself only.) Or does that trample on her rights?

And if you are unwilling to say that the maintainer ought to log off, what does that make the maintainer? Are you going to claim that they have (a) started an altruistic hobby by themselves (b) got too caught up in it and (c) are now a victim of circumstance/outside forces because they have no moral obligation to log off? Considering how much power the maintainer has (and how the consumers have none), how is the maintainer a victim of circumstance when the whole enterprise was created by them and can be terminated at will by them?

Re: Xz: A microcosm of the interactions in open source projects

#43
post #39

So the first step of this huge mess was: a social engineering attack. Attacking a tired, burnt-out open source project developer and peer pressuring him into giving more control of the repo to the attacker.

In the end you're only pressured as much as you allow yourself to be pressured. "I don't feel like it, if it's important to you then feel free to fork". That's really all that's needed. "I don't feel like it" is all the justification you need. Some guy just made a compression tool, because some people like doing that kind of thing, or because it was useful for him. He didn't ask to be made "critical infrastructure" o…

When it was created, it was a different time. There was a sense of community around open source, much more tightly nit. And the more socially minded you are, the more vulnerable you are to these kind of attacks.

Re: Xz: A microcosm of the interactions in open source projects

#44

I'm starting to feel that one of the lessons here is that individuals invited into trusted positions should be identifiable. Jia Tan is not a real person. We don't know who they are, so there is no way to hold them accountable.

As much as I support the privacy of maintainers I do feel like this is necessary to raise the bar for these types of social engineering attacks. However that would've likely done little to impede this attack if it is backed by organized crime or by a state as is being speculated. It is trivially easy for those types of actors to simply use a stolen identity or create an entirely plausible one out of thin air.

Such identity checks would also hurt honest contributors who want to hide their identity for other, legitimate reasons.

Re: Xz: A microcosm of the interactions in open source projects

#45

So the first step of this huge mess was: a social engineering attack. Attacking a tired, burnt-out open source project developer and peer pressuring him into giving more control of the repo to the attacker.

I often debate if I should go into the hacking world, best case I get bug bounties, worst case I get rich and I contribute immoral actions. I think its far easier to make $3,000,000 as a hacker than a worker/entrepreneur. Its way easier to find flaws/bugs than to do the entire Capitalism thing correctly. Then I see that half of these major attacks required social engineering.... Maybe being a hacker is significantly…

> People are amazed by hacking, they shouldn't be, its relatively easy if you are a mere 10 year programmer.

+1

Between roughly 1999 and 2013 I was primarily a test engineer for networking switches/routers/telephony products. I found bugs for a living and wrote them up, and in the process I found plenty of security vulnerabilities and wrote them up. Security bugs aren't really that different from other bugs. Yet for some reason we lionize people who find security bugs.

Most security issues are simply quality issues. But by calling them security issues we shift the focus away from the software producer creating shit code to an attacker doing something bad.

The case with xz is a little different, because we have someone who intentionally added bad code and tried to hide it. But for unintentional bugs that rise to security vulnerabilities it's 99% a QA problem.

Re: Xz: A microcosm of the interactions in open source projects

#46

I'm starting to feel that one of the lessons here is that individuals invited into trusted positions should be identifiable. Jia Tan is not a real person. We don't know who they are, so there is no way to hold them accountable.

Reputation works with pseudonymous identities too, and those have security upsides (eg can't be as easily pressed into service of others by extortion or rubber hose). And of course privacy is a value in itself.

Re: Xz: A microcosm of the interactions in open source projects

#47
post #26

Earlier quoted context omitted.

Are these customers or additional attackers who have never posted before and will never post again?

Tired maintainers have no way to distinguish one from the other, that's the problem. Even if we say "no payment, no customer," it won't prevent determined attackers from paying significant amounts of laundered money in order to be treated as customers.

Also one thing that is easy to come across at this type of work is money. I mean in the cases where someone is injecting backdoors or vulnerabilities. Might not be for individuals or criminal groups. But once agencies and corporations get involved, the sums are trivial...

Re: Xz: A microcosm of the interactions in open source projects

#48

“Community desires more” At which point if “the community” consists of one guy doing everything and a couple whiners making demands, fuck it.

I by default distrust any statement that claims to speak on behalf of some community.

Re: Xz: A microcosm of the interactions in open source projects

#49
post #43
post #39

Earlier quoted context omitted.

In the end you're only pressured as much as you allow yourself to be pressured. "I don't feel like it, if it's important to you then feel free to fork". That's really all that's needed. "I don't feel like it" is all the justification you need. Some guy just made a compression tool, because some people like doing that kind of thing, or because it was useful for him. He didn't ask to be made "critical infrastructure" o…

When it was created, it was a different time. There was a sense of community around open source, much more tightly nit. And the more socially minded you are, the more vulnerable you are to these kind of attacks.

2007 wasn't that long ago, and these type of maintainership issues aren't new – they were a thing when I was starting out in the early 2000s as well. What changed are the stakes, and also the amount of effort bad actors are willing to spend to mine their cryptoblahblah or whatever.

And sure, I understand why people feel a responsibility. And it's fine to take this responsibility too. I'm just saying: there is no need to.

The entire point of this Free Software/Open Source is to give people the freedom to do whatever you want with some piece of software, without having to be beholden to the original author. That's pretty much the entire point.

Anyone in the world can be a maintainer for xz. By forking it and applying useful patches.

Re: Xz: A microcosm of the interactions in open source projects

#50
post #5

awkward, but heard very recently that open source is not "vc backable, go away". maybe it will change now, after the infrastructure pillars of the modern world ruins in front of those many saas/ai/web3/cloud/whatever investors

Why should VCs back oss infrastructure directly? It doesn't help the VCs and only creates perverse incentives for the oss projects. The SaaS/cloud/etc. companies themselves should fund the projects they depend on. They actually know what those are and don't have to force their own monetization/growth models onto the projects.

definitely. not talking about the vc specifically, but the investment chain. a typical free rider, directly or indirectly.
Post reply on HN