“the lesson I'm choosing to take from xz, as an oss maintainer, is that anyone trying to pressure or guilt me into doing something should immediately be told no, for security reasons”
“the lesson I'm choosing to take from xz, as an oss maintainer, is that anyone trying to pressure or guilt me into doing something should immediately be told no, for security reasons”
the lesson *I'm* choosing to take from xz, as an oss maintainer, is that anyone trying to pressure or guilt me into doing something should immediately be told no, for security reasons
In some open source projects there is a lot of leeching and little contributions.
In 2020 the sole developer of Invidious stepped away from development because of burn out. https://omar.yt/posts/stepping-away-from-open-source
Also in 2020 developer Raymond Hill archived the uMatrix browser add-on https://news.ycombinator.com/item?id=24532973
I will never hand over development to whoever, I had my lesson in the past -- I wouldn't like that someone would turn the project into something I never intended it to become (monetization, feature bloat, etc.). At most I would archive the project and whoever is free to fork under a new name. For now I resisted doing this, so people will have to be patient for new stable release.
What would actually help is that people help to completely investigate existing issues instead of keep asking me to add yet more features. Turns out people willing to step in the code to investigate and pinpoint exactly where is an issue (or that there is no issue) is incredibly rare.
That last sentence rings true of most software engineers. Everyone wants to work on a glamorous new feature that's going to wow users or let them think about problems they want to think about. No-one wants to hunt down the difficult-to-repro bug in an old but critical section of someone else's code.
For anyone wondering, here is the difference between uMatrix and uBlock Origin: https://news.ycombinator.com/item?id=24533329
When I stepped away from my own (mildly successful) Free software project, I had the same concerns: it's about the reputation.
The project had earned a decent amount of trust when I was running it, and presumably people were installing new updates without going over the changes. If I handed off the project to someone new, I wasn't just handing over the work, but that trust as well.
So rather than handing over the project to someone new, I archived it and someone else (thankfully someone not-evil) forked it. Anyone installing the fork immediately understood that the relationship was new. They'd have to decide whether to trust this new maintainer or not.
For my money, this is the way. If you're burning out, remember that your reputation is tied to your project name, and that it has considerable value. If you don't want to continue, the disruption of a fork is better/safer than the smooth-but-risky hand-off.
More people need to operate like Linus Torvalds. Call people on their shit. Respectfully of course.
Fuck you
Respectfully,
Linus Torvalds
Shit, sensitivity training works. Please don't show this to my HR team....
Thing is, much of what Linus says is respectful; even though it reads harsh. Phrases like "you keep doing this" and "your code is shit" and "I will bar you from committing code until you can get better" and similar stuff, is respectful to the person, as he is still just focusing on the code : the product. Mostly.
Sure it comes off as aggressive ultimatums, but when I worked on New Jersey I saw numerous arguments between passionate coders who really cared about their work and spoke on these loud voices with aggressive gesticulations and gestures, and it was frightening. But, when you took apart the arguments, it was all about "the code" this, and "the standard" that, and very little "you suck" and "you're dumb". And, when the argument was settled, these passionate people were still friends.
Of all the people I've been yelled at by in my career, the harsh-sounding ones who kept it on the work and not the worker ended up with the most loyalty and trust in the end.
Give me a dozen Linus who care about their work. Sure he's slipped up a few times, but on balance he's been very good. Even before the "let's all hug" sensitivity training.
Permanently Deleted
Sure it comes off as aggressive ultimatums, but when I worked on New Jersey I saw numerous arguments between passionate coders who really cared about their work and spoke on these loud voices with aggressive gesticulations and gestures, and it was frightening. But, when you took apart the arguments, it was all about “the code” this, and “the standard” that, and very little “you suck” and “you’re dumb”. And, when the argument was settled, these passionate people were still friends.
I used to work for a guy like that. He was aware of how a lot of people perceived him and was working on it but it never really bothered me when he slipped because like you said it wasn't a personal attack, he was just trying to make us get the work done to his standards. There were multiple times he would come to me and apologize after we finished something and I was just like "well you were right so I'm not really worried about it".
"You're dumb" is disrespectful, but "your code is shit" isn't? How does the latter not reasonably imply the former?
Being respectful is taking the time to moderate "your code is shit" to something like "your code is not acceptable". You might even go a modicum further into kindness with "there are aspects of your code I need you to improve".
All express the same idea, some will leave the listener more open to internalizing the criticism.
Respectfully of course.
Like "Fuck you Nvidia"?
I vote on an exception for big corps. Fuck you nvidia.
Respectfully
I'm more of a fan of responding in kind. Manners may cost nothing, but so does clear communication.
In my book, respectfully is something more insulting than "you're so stupid, how did you survive to suck on your mother's tit, one would imagine you were too stupid to know what to do with it".
Obligatory /s
Lol, you don't already operate this way in life?
Someone trying to guilt or pressure you has an agenda and isn't concerned with what's best for you.
Easy to say... Not so easy to just do it, specially if you're burned down..
This very comment could be very dismissed with the attitude.
Yes, you should totally do that. DO IT.
No. I won't not do that. For security reasons.
Open source is such a wild west at times.
You have your gatekeepers like Linus Torvalds who will call you a fucking moron if you submit something that looks remotely off.
You have your committees that you can submit a MR, but it has to go through the council of experts before it gets merged.
But the vast majority, it's a one or two person project and this was a side project because you had an issue you wanted solved. No financial reward, no acknowledgement. And so when someone gives it a iota of attention, you fall head over heels and hope they are like-minded and want to support this dream too.
I've always taken this attitude towards pushy people and tbh this is more or less why. Being pushy like this is inherently suspicious as fuck.
I think it can depend on how and why you're being pushy too. I've definitely had to have my fair share of passionate conversations and strongly advocating (yes, you could say pushing) for what I believe is best for the direction of a project with my fellow maintainers, especially when it comes to important things (like how to handle specific security issues etc since there's not always one way of handling it). Generally speaking though you're right.
Yeah, that's fair, there are driven people, and people who are pushing for something, right, but in this case, look at the language used:
Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn't care to maintain anymore. It is sad to see for a repo like this. [src]
Tons of emotional button-pushing and pressure, but not on technical grounds. Just trying to make the dev feel crappy about themselves.
Anyone pushing you to do something you don't understand, or understand poorly. I could see an actual security researcher pushing for a code update to fix a vulnerability.
Heck, even as an occasional contributor I take some pride in seeing my fixes etc make it into the mainline codestream.
But yeah, you definitely need to be wary of somebody you only know from online pushing a change that doesn't make sense or you don't understand.
Anyone pushing you to do something you don’t understand, or understand poorly.
This was taught to me in my bank teller training back in 19-dickety-two. Don’t let someone try to rush you or to obfuscate/over-complicate things.
I've always been a fan of "pull requests welcome" when someone asks me for something.
The problem is when people then open huge PRs and expect you to take time to review them, then eventually merge them.
Especially when it's something you don't want in your codebase because it introduce a big unnecessary "refactoring" or a feature that you don't want to have to maintain forever.
I can’t imagine just opening a giant PR without having extensive contact and coordination with the maintainer. Almost any amount of incremental safe steps would be preferable to a giant PR, even with extensive communication. I once introduced fully strict typescript into a vanilla js codebase and it took dozens of small PRs to do so. It was made more complicated by the fact that it was a library, but still. The communication made the entire process smooth and let everyone be confident the changes were correct along the way. If I’d done it all at once without any coordination, it would have been faster for me, but at the cost of the maintainer’s sanity and time.
That doesn't apply as a solution here. After all Jia Tan did make pull requests, the pressure came later.
Honestly that should go for all transactions. someone calls you to fix an issue or pressure you into buying something. Just hang up and call the company back. one thing I have learned from many years of support is the person calling always has power over the person being called. So flip the dynamic. same goes for car sales just walk away. hell go look at cars when you don't want one and practice just walking away and see how much power you get.
Regardless of flipping the dynamic, that's a good way to avoid scammers. It's easy to spoof an incoming number, but near impossible to intercept an outgoing call. If your "bank" calls and starts asking funny questions, just hang up and call the real bank to check.
as a non developer myself, to my understanding, the vulnerabilities were implemented in test binaries?
If so, i question why those were shipped to the client. Unless they were built into the package itself on the mirror, in which case, still curious as to why that would be. I would think tests are entirely benign and do nothing. Seems like it would be incredibly bad practice to do otherwise?
Seems like an obvious vector to shutdown any potential fuckery. But what do i fucking know.
The compile process was modified to decrypt and unpack the "corrupted" test zip file, which was actually a code patch, and apply said code patch before assembly of the final binaries.
hmm ok. Yeah idk, even from an organization aspect, i still wouldn't consider that to be ok. Test files that patch code on the fly is a recipe for a nightmare of maintenance. Which i suppose is the idea here considering that it's malicious code lol.
They were not shipped to the client. They were shipped to the build system, executed there after deobfuscation, and they inserted an additional, opaque program file into the build process.
that much i picked up on, though i didn't make it very clear. I did mention that alternative though.
It is way more complicated than that. Very good explanation, I could never do it justice.
Edit: I found an even better one https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/
i know it's rather involved, i've been tailing it from the sidelines, though like i said, i am not a developer, so in terms of code and maintaining code im blind there. But everything else i understand.
It's definitely an interesting situation to observe.
It's common to bundle test artefacts with the release tarballs. The reason is that when Linux distributions build the software from the tarballs, they often run the tests to ensure that they pass.
It's a hard call at end of day. If you want it to all be privacy respecting and open source and decentralised then you're almost guaranteeing you won't make money from it.
The alternative is ad based software that's free which is also garbage.
Hard to find the balance between the two, can't think of many examples if any that actually work besides just making a paid product that's very good and hope it's better enough than the rest to be successful. But even then you likely will have to cross lines because you're just relying on viral luck at that stage.
The guy was from Hong Kong, they probably threatened to throw his family in jail.
he was using a singapore VPN and had access to multiple sockpuppets. we know literally nothing else about them and anything you've heard to the contrary is baseless rumor.
leading theory is that it was a state-sponsored actor, but frankly even that much is speculation and which state is still way up in the air.
Via https://boehs.org/node/everything-i-know-about-the-xz-backdoor
They found this particularly interesting as Cheong is new information. I’ve now learned from another source that Cheong isn’t Mandarin, it’s Cantonese. This source theorizes that Cheong is a variant of the 張 surname, as “eong” matches Jyutping (a Cantonese romanisation standard) and “Cheung” is pretty common in Hong Kong as an official surname romanisation. A third source has alerted me that “Jia” is Mandarin (as Cantonese rarely uses J and especially not Ji). The Tan last name is possible in Mandarin, but is most common for the Hokkien Chinese dialect pronunciation of the character 陳 (Cantonese: Chan, Mandarin: Chen). It’s most likely our actor simply mashed plausible sounding Chinese names together.
Wild, so it would suggest that the actor wasn't Chinese at all. An authentic Chinese person probably wouldn't choose a name that sounded like that, any more than I would name myself Sean MacBerkowitz, it would just sound wrong.
A random name generator might produce something like this, of course, if it wasn't programmed to be too picky.