Xz: A microcosm of the interactions in open source projects • Hacker News Board

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

#181

Post by EasyMark » Sun, Mar 31, 2024, 1:39 PM UTC

arp242 wrote: post #39

SuperHeavy256 wrote: post #10

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…

This is harsh but tree, but it's not simple. People are different. Some shrug off things naturally, others try to be empathetic almost to a fault. I've learned to be the former, but when I was younger was much more the latter. I try not to act like it's easy because it took me a while to have that skill. And it is a skill and not built in to me, I still feel the urge but built up the skill of saying "no"

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

#182

Post by EasyMark » Sun, Mar 31, 2024, 1:42 PM UTC

tonnydourado wrote: post #146

arp242 wrote: 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…

The maintainer did mention mental health issues. It can be hard to say no in the best of times, let alone when your own mind is trying to screw with you.

That's brave on his part and honest. I would never admit that in public personally and shows his personal level of honesty, unfortunately it can make you the victim of even more predators. Just say "no" and move on with your own agenda on your own personal projects. It's none of anyone's business, but one may share at times, just realize that others may try to take advantage. That's just my take.

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

#183

Post by mustache_kimono » Sun, Mar 31, 2024, 1:43 PM UTC

jpz wrote: post #176

I think the idea this was HUMINT operation by a state sponsored intelligence service is more likely. The twitter thread here was interesting. https://x.com/thegrugq/status/1774392858101039419 Raging about these being inconsiderate people, when they were likely fictional personalities that were part of a long con seems to be a bit foolish to me.

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

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

#184

Post by _kb » Sun, Mar 31, 2024, 1:43 PM UTC

AndyMcConachie wrote: post #45

resource_waste wrote: post #33

Earlier quoted context omitted.

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…

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, invalid designs, unsound architecture, inaccurate documentation, ambiguous requirements, and a myriad of other ways to express how software may be defective.

Using those terms hurts, and may even invoke some level of concern from those outside of the engineering org - this is a great reason to embrace them.

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

#185

Post by apantel » Sun, Mar 31, 2024, 1:45 PM UTC

bregma wrote: post #107

kimixa wrote: 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…

Thank, you for participating in the open source community by sharing your opinion. Your contribution is valuable but not consistent with the direction we are currently going in at this time. Please don't let this stop you for further participation.

There are no stupid contributions, just stupid people.

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

#186

Post by higeorge13 » Sun, Mar 31, 2024, 1:46 PM UTC

Serious question, but what is your expectations for linux and all these libraries/dependencies after 20-40+ years when most of old school or current devs are retired? How can anyone guarantee reliable continuity by good actors in all these dependencies?

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

#187

Post by ploxiln » Sun, Mar 31, 2024, 1:47 PM UTC

em-bee wrote: post #60

arp242 wrote: 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…

"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 and this whole "the community demands vibrant evolution of the project" thing. xz does its job already!

And being rude/mean is not a plus, it's a minus, but it does seem to correlate strongly with leading a high-quality project. Even if it's not the best way, this person has the guts to say no in unequivocal terms. You might just have to accept the downside of a rude/mean maintainer as a common unwanted side-effect of an effective maintainer. (Linus Torvalds also comes to mind of course.)

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

#188

Post by noobermin » Sun, Mar 31, 2024, 1:47 PM UTC

nuc1e0n wrote: post #157

My take away from this is that people are still far too blasé about introducing hard dependencies and complexity, even after the left-pad incident as a warning. OpenSSH is a massive wall of code. Such complex systems are inherently untrustworthy to me, no matter what language they might be written in. Even with ernest devs there are still more opportunities for mistakes.

This wasn't a vulnerability in openssh though, this was from systemd, where I think your point in fact is stronger.

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

#189

Post by nebulous1 » Sun, Mar 31, 2024, 1:47 PM UTC

rafpin wrote: 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…

Well, it appears that it would be as safe as any other vulnerable server behind port knocking. Although there's still the possibility that the backdoor is doing something we aren't aware of yet. So yeah, it's as "safe" as you consider port knocking to be.

That said, just make sure you aren't using the backdoored versions. I don't see how you can reasonably skip this step.

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

#190

Post by ris » Sun, Mar 31, 2024, 1:49 PM UTC

lrvick wrote: post #179

nuc1e0n wrote: post #157

My take away from this is that people are still far too blasé about introducing hard dependencies and complexity, even after the left-pad incident as a warning. OpenSSH is a massive wall of code. Such complex systems are inherently untrustworthy to me, no matter what language they might be written in. Even with ernest devs there are still more opportunities for mistakes.

Agreed, which is why IMO ssh in production is a terrible idea that reveals even worse problems. A server with ssh generally implies there is a shell, and cli tools, and an administration model that involves humans connecting to servers to manually update them in place like pets. Having a full workstation-optimized distro like ubuntu or debian with hundreds of packages constantly shifting and updating as a critical pr…

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