> 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.
Xz: A microcosm of the interactions in open source projects
281–290 of 353 posts
Re: Xz: A microcosm of the interactions in open source projects
#282Sadly, 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.
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
#283Earlier 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…
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
#284Earlier 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,…
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
#285Earlier 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.
Re: Xz: A microcosm of the interactions in open source projects
#286So 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…
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
#287Earlier 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).
Re: Xz: A microcosm of the interactions in open source projects
#288Earlier 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…
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
#289Earlier 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.
Re: Xz: A microcosm of the interactions in open source projects
#290Earlier 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.
- 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.)