Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

21–30 of 353 posts

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

#21
post #11

Earlier quoted context omitted.

> Help in maintainship how? Pay.

Huh? So anyone who asks/says something in OSS, should just throw money into the ring to have an opinion?

No. But if the maintainer is burning out and doesn't have free time available for it, paying them so they can take time off to actually work on the thing is a nice way of fixing issues.

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

#23
post #11

Earlier quoted context omitted.

> Help in maintainship how? Pay.

Huh? So anyone who asks/says something in OSS, should just throw money into the ring to have an opinion?

No, maintaining such software should be a paid job. Not that that guarantees all, but it could be a step.

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

#25

The Jigar Kumar account should be treated with extreme suspicion. It seems like it was part of a social engineering attack.

Given how all participants in the discussion were very focused on transferring ownership to the attacker I'd treat everyone in the entire e-mail thread with suspicion. I would not be surprised if Dennis Ens, the one who started the thread in the first place, was also a sock puppet of Jia Tan.

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

#26
post #12

Earlier quoted context omitted.

Enabled by customers who don’t pay or donate.

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.

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

#27
post #22

Considering how kind(naive) our open source projects maintainers are, backdoors are probably already everywhere.

theyre much harder to add if people use a buildsystem from the last, idk, 20 years

Didn't Jia Tan add a single '.' in cmake script to disable the landlock?

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

#28
post #8

Earlier quoted context omitted.

> Help in maintainship how? Pay.

That assumes the maintainer wants to be paid. There are plenty of us who maintain FLOSS projects that do it for other reasons and any monetary exchange would burden us, since it might pressure one that this is now a job and you have to execute on tasks - there are enough headaches handling other things as it is.

Agreed - I already have a job where people come asking. If developing OSS came with obligations, I’d do something else instead.

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

#29
post #22

Earlier quoted context omitted.

theyre much harder to add if people use a buildsystem from the last, idk, 20 years

Didn't Jia Tan add a single '.' in cmake script to disable the landlock?

That was some sort of theoretical security loosening, it didn't contribute to the backdoor.

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

#30
post #17

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.

The tiredness or other problems of the developer seems an easy narrative, but did anything actually happen that wouldn't in any understaffed open source project? A contributor shows up and does work for 2 years, I feel most projects would have given the person full project developer status by then.

It's not like organizations writing proprietary software are magically immune to sleeper agents either. Social engineering is not a software or tech problem in general. Trust is required to get anything done, and can also be abused to hell and back by a sufficiently motivated actor.

But important software needs to be identified and proportionally more scrutinized by multiple independent parties, that's the lesson. Identification is the hard part. You can't easily determine that half of the world relies on this particular piece of software, or that it enables access to desirable targets.

Post reply on HN