Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

231–240 of 353 posts

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

#231
post #124
post #108

Earlier quoted context omitted.

there are cultural norms and expectations at play here, which I feel need to be modified somewhat this is an important observation. a change of culture is really what is needed here, because it implies that not only maintainers change their behavior, but everyone involved, and the question is not so much what any individual can do for themselves, but how we can help others with that change and spread it

It's impossible for everyone to change their behaviour, because that's too many people. Some people are just assholes and don't care. Or they're idiots and don't understand. Nothing we can do about that. Most people are alright, but with 8 billion people on the planet even a small percentage being an asshole means a lot of assholes. For the most part, the people who care already care (you, me, most others commenting…

i would not say it's impossible, but for sure it's an uphill battle. and it might take a few centuries for people to change, just like it took a few centuries before we abolished slavery and we are still working on racism, gender, different orientations, etc.

being nice to each other is just one of the many things that we as humans need to work on. and we are working on it, and hopefully some day we will be able to achieve it.

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

#232

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.

Here's the deliciousness:

Let's take on face value that it was the Chinese, and that China is communist. I mean, "Kumar" and "Tan"? Maybe it wasn't, but it doesn't matter for my purposes:

They took an overworked peon of the capitalist enemy that provides a ...

... do I even need to expound? well it's fun ...

... collectively and idealistically produced common operating system "for the people"

... that is exploited and neglected by the rich and powerful, to a degree that society, not just computers, overall society operates on this operating system, and the profits from that are hoovered up by the powerful.

The communists attacked the exploited proletariat to get to the enemy. And they are forcing the enemy capitalists to either pay the proletariat properly (they won't) or continue to be vulnerable to the growing communist power in the far east.

That's what this distills so well, within a political/ideological conflict that has now spanned 100 years: capitalism vs communism.

To wit, a proper functioning capitalist system to reward market value for produced value would properly pass compensation to this poor soul, and incentivize others to help him. Barring that, a proper functioning government would recognize the public good of this and provide support to the core infrastructure software to enable other private enterprise to produce tax revenue.

THOSE AREN'T HAPPENING, so the Communists can attack this with impunity and in perpetuity.

Here's the thing folks, we've been living in, as they used to say "uninteresting times". Post-WWII Pax Americana, even the Cold War was basically peace, has been cranking for 80 years now.

People, that is coming to an end:

- Russia / China are destabilizing demographically and simultaneously becoming militant and totalitarian

- Global Warming will ramp up the pressure on populations, food shortages, production

- The US will likely retreat to a more regional focus as production is onshored, regionalized (or at least centralized to our hemisphere)

There's going to be more state conflict, the Ukraine war is just the beginning. The world stakes are rising.

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

#233
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

My layperson’s opinion is that anything to do with gaming is particularly riddled with people that interact poorly with maintainers. Again, purely my opinion: gamer culture invites a particular sort of Dunning-Kruger-prone ‘power user’ type. Every gamer community carries with it a corpus of baseless, fictitious, technical information. “The developers didn’t do this because x”, “it’s ridiculous that they didn’t just y…

The gamers seem to have particularly short fuses. It's like they skipped the socialisation phase of childhood development.

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

#234
post #171
post #165

Would ssh servers with port knocking set up be safe from this backdoor? I'm not sure I got it correctly, but seems the RCE can only be performed after connecting to the ssh server, but if the port is hidden behind a reasonable sequence of tcp/udp knocks, then it won't happen? I've been using port knocking on ssh servers, and it definitely does not replace proper ssh configuration, but so far seems like a cheap extra…

I do not use or recommend security through obscurity. Such things can always be automatically discovered. https://github.com/eliemoutran/KnockIt Any effort spent on setups like this is likely better spent removing the need for having ssh at all by moving to immutable appliance distros be they specialized like homeassistant or general purpose like TalosOS.

> Such things can always be automatically discovered.

Wouldn't fail2ban + reasonably sized (10+ ports using a mix of udp and tcp) knock sequence prevent brute force attacks like these?

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

#235
post #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.

Think of it like politics: politicians are public figures who, by virtue of becoming a public figure, give up many of their rights to privacy. Why? Because they have power, and the public has a right to know who exercises that power.

For security-hardened distributions, I can easily imagine a security control where contributor identity must be public and publicly verifiable, and to reject code which cannot be reliably attributed. Don't like it? Contribute to software with less impact instead.

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

#236
post #65

Earlier quoted context omitted.

You dont need to wonder. Any long term maintainer of even semi popular open source projects will tell you that engaging with the peanut gallery is completely counter productive. Engage with people that have earned it in your eyes, whether by contributing to your project via code, assets, bug triage, writing a good and effortful bug report, whatever. Just ignore what the larger internet has to say about you and your c…

What form should this ignoring take, in your eyes? I’ve never maintained an open source project but I’d imagine this is the hard part, how to politely decline the peanut gallery’s feedback. Do you disable GH issues? Leave them open and ignore them? Decline with some boilerplate language? How do you stop people from being mad that you’re ignoring them? (IME these types of people are likely to take things personally an…

A relevant term is "help vampire". The original post describes how to spot them, and suggestions for addressing it.

https://slash7.com/2006/12/22/vampires/

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

#237
post #60

Earlier quoted context omitted.

"I don't feel like it, if it's important to you then feel free to fork". That's really all that's needed. that's much harder than it sounds. having someone fork your project can give you the feeling of loosing control over the project as potentially all your users might go with the fork. that fear is often strong enough to push yourself to do things that will avoid a fork. it's a desire for harmony and a fear of conf…

I'm reminded of this recent post about the Redis fork to be maintained by Drew Devault: https://andrewkelley.me/post/redis-renamed-to-redict.html > Redict is a Finished Product > Drew is a controversial person (he's been rude/mean in the past) xz should be pretty much finished as well, major overhauls like the "ifunc" feature to inject alternate function implementations are not really justified. Beware of busybodies…

I've made absolutely stupid 'contributions' to open source projects in the past, not out of malice but pure ignorance.

If someone had slapped me down for being an idiot I'd have most definitely found something else to spend my free time on.

Today, I'm not super great at coding but can hunt down segfaults like a truffle pig and submit bug reports (with code) that demonstrates the exact issue if it's something I can't figure out on my own.

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

#238

The multi-entity (sock puppet or not hard to say) social engineering attack that was apparently two years in the making (?), is to me a much more salient story than "users are often mean." Although it's true that the expectation of mean users let the attack fit right in, I guess.

The "users are mean" story is something that we can all do something about, and, honestly, I prefer stories with morals that most of us can actually put into practice.

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

#239
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

Boomer hat: it's just toxic positivity, and the frustrating trend lately of assuming that everyone is equally skilled when writing software. Everyone's input is valid, or else you're just being negative and overly critical. I'm not saying everyone need to be Linus Torvalds circa 2012, but I do think more people need to be a bit less precious and sensitive, especially when receiving direct communication about their ab…

Another old person opinion: the issue tracker of an open source project needs to be firmly anchored into the needs of the maintainers and not the users. The argument that bugs/issues need to be kept open forever unless they're fixed and the rejection of WONTFIX as a reason for closing them needs to die in a goddamn fucking fire. When the maintainer decides to close an issue because they're just not getting to it in this lifetime the users need to suck it up.

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

#240

The multi-entity (sock puppet or not hard to say) social engineering attack that was apparently two years in the making (?), is to me a much more salient story than "users are often mean." Although it's true that the expectation of mean users let the attack fit right in, I guess.

The "users are mean" story is something that we can all do something about, and, honestly, I prefer stories with morals that most of us can actually put into practice.

Ah, well, I guess my thought is that we need to figure out what to do about the "take over from a burned out maintainer and then inject malware" attack.

It's not obvious what to do about it to me either. Which is why I'm concerned to talk about it.

That this attack was run by someone who had been participating in the project for possibly years before making the attack -- is not what i would have expected, and makes it even much harder to defend against. Before I was thinking it was about awareness of "don't just turn over the thing to someone new who just showed up, they might be an attacker." But not that easy in this case.

I suppose "try to get users to be less mean, by doing our part by being less mean individually" is arguably one piece of strenghtening defenses to this kind of attack, I guess, ok.

Post reply on HN