Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

281–290 of 353 posts

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

#281

> This thread is a microcosm of the interactions in Open Source projects. Consumers make demands (some polite, some not-so-polite) of one maintainer (rarely two) that does everything. > Make no mistake. This is the way it works. > It needs to change. How?

Deny by default anything from a State that's hostile to American interests.

How would that help with the problem of people being rude to unpaid OSS maintainers?

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

#282
post #35

Sadly, this is how it works in many large social systems, left unchecked. The “reasonable consumers” drain the kind contributors until they cannot do this anymore. The curse of kindness strikes in software and other industries alike.

This is all due to the ongoing attempt to convert FOSS into an obligation. The original idea behind FOSS was to code to scratch your itch and then leave it out there for anyone to find, modify and use. Instead we now treat FOSS code like commercial projects with performance goals and expectations.

Why? My guess is that this new culture is promoted to extract free labor from hobby developers. Take for example, Github. It has a bot to close stale issues after a given interval of inactivity. But what if the issue was valid and unresolved? What's the problem in leaving it open for someone interested to take it up? But what GH wants to promote is a culture where open issues are considered as bad performance on the maintainer's side. It indirectly prompts the maintainers to take open issues too seriously.

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

#283
post #96
post #49

Earlier quoted context omitted.

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…

2007 was 17 years ago, and it was another world. This time 17 years ago, the iPhone had not been released. Facebook was still new and hot, the first big operation to be unashamedly built on PHP (!). GitHub didn't exist , opensource happened on mailing lists, Sourceforge, private Subversion repos. It was definitely another world. I do agree that maintainership issues were already there, but I think they were smaller i…

PHP was a popular stack at that time ? Wikipedia and Wordpress existed and were very popular and unashamedly PHP.

What PHP lacked and Ruby had was rails like framework , the team from 37signals singlehandedly shifted the momentum out of PHP with their work on rails.

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

#284
post #184

Earlier quoted context omitted.

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

QA is focused on testing a product or system against how it should work. Security analysis tests against how it shouldn't. The second of those is a much larger search space. Both are important. The argument around blame shifting is apt. The same case has been made for the usage of the term 'bug' (aka an externality). It's 2024, we don't have moths crawling into relays on our computers. We have implementation faults,…

> QA is focused on testing a product or system against how it should work

It would be pretty poor QA who only tested happy paths . Any competent quality analyst will be expected to test for failure states, boundary conditions and so on .

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

#285

Earlier quoted context omitted.

I agree. Either native English or very very good second language. Given the weird laziness of some parts of the attack I'd put my money on native English.

It sounds to me like you're trying to seek a correlation too eagerly. It's not obvious whether it's more implausible that he's a lazy Chinese programmer with very good English, or a lazy native English-speaking programmer who wants to pretend to be Chinese.

The former is more implausible because Chinese people with that level of English are quite rare, whereas English people able to create a fake Chinese username are not.

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

#286
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…

I'm curious: do you maintain a popular open source project?

The reason I ask is maybe the people who do are (in general) self-selected from the subgroup of people who don't just say "sod off" when someone is rude or inconsiderate.

If that was their stance in life, they would likely not put up with maintaining a popular open source project for very long.

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

#287
post #83

Earlier quoted context omitted.

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

That’s of course a fine approach for you. I think a big part of the problem in this case is not with the maintainer, but with the critical software that took a dependency on this hobby project (in the maintainer’s own words).

Agreed.

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

#288
post #260

Earlier quoted context omitted.

> I think the idea this was HUMINT operation by a state sponsored intelligence service is more likely. It's not an either/or proposition. I definitely think it was state sponsored, AND one method used was social engineering a burned out maintainer.

It seems to me that people are very much exaggerating how "professional" this attack was. Yes, it doesn't look like the actions of a single bored teenager but I don't think the government of a country like the USA or China would deliberately permit their employees to get involved with crap like this. Any backdoor they try to insert would look exactly like an innocent bug. So my (uninformed) guess would be that this i…

> I don't think the government of a country like the USA or China would deliberately permit their employees to get involved with crap like this.

Not the USA, but I can easily imagine this is China. Because, as of right now, this seems like the way China does business. The Chinese/the PLA fund a hacking complex of contractors, and when one gets caught, they simply deny involvement. [0],[1]

[0]: https://www.npr.org/2024/02/22/1233178131/leaked-document-tr...

[1]: https://www.washingtonpost.com/world/2024/02/21/china-hackin...

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

#289
post #248
post #190

Earlier quoted context omitted.

> Production servers should be hardened immutable appliance kernels with read only root filesystems that verify and run signed containers, or run a tiny shim init system in a couple hundred lines that spawns a single application specific binary you trust. And then you need to debug something. What do?

Debug it with a binary with debugging enabled on a debug dev system. Just like you would any other immutable firmware appliance. You could also in some cases have a debug container you pull in on demand, say if the host OS is an appliance-style k8s runtime like TalosOS.

Except the debug environment isn't _quite_ like the production environment, is it? Now you've got it working on the debug environment but weirdly broken on prod still..

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

#290

Earlier quoted context omitted.

It sounds to me like you're trying to seek a correlation too eagerly. It's not obvious whether it's more implausible that he's a lazy Chinese programmer with very good English, or a lazy native English-speaking programmer who wants to pretend to be Chinese.

The former is more implausible because Chinese people with that level of English are quite rare, whereas English people able to create a fake Chinese username are not.

I feel like you're making three statistical mistakes at once.

- First, we're not discussing the English level of the general Chinese population, but specifically of the group that's also good at programming. That conditional probability is much higher.

- Even if we did speak of the general Chinese population, that is a lot of people so something rare in that group is true for many people still!

- It's not like everyone in the US has great English either. (Though open source maintainers are again probably more likely to.)

Post reply on HN