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.
The point is that saying “pull requests welcome” is still work for the maintainer, because now you have to have these discussions with potential contributors, sometimes explain them why you don’t want to maintain the feature, or explain them why this PR is not the way you want…
So either way it’s work, it’s important to keep in mind before saying “just send a PR”.
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.
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.
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.
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.
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.
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.
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.
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.
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.
If you’re rooted enough in your life to just recognize the problem and fix it, yes. But for all the younger, inexperienced people, a sprinkle of compassion and help on top of being strict is a good idea, otherwise some or most of them can’t ever reach that point.
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.
Stuff like this is a big part of why software circles are seen as so hostile and unwelcoming to outsiders.
You can be completely clear and frank without resorting to insult, mild though it may be. Just because you and people most like you understand that calling their work ‘shit’ doesn’t reflect on them personally, doesn’t mean it’s not significantly exclusionary.
Now, obviously you can get to know your reports well enough to understand whom would take ‘shit’ well, but that doesn’t mean it’s not generally important to temper criticism with kindness. Kindness never has to mean holding back criticism, just avoiding stooping to insult.
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”.
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.
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.
we know about the singapore VPN because they connected to IRC on libera chat with it. the only reason I can think people would believe they’re from hong kong is because of the pseudonym they used, but it’s not like that proves anything.
we know about the singapore VPN because they connected to IRC on libera chat with it.
Hmm.
I don’t know if the VPN provider is willing to provide any information, but I wonder if it’s possible to pierce the veil of VPN in at least approximate terms?
If you have a tcpdump of packets coming out of a VPN – probably not something that anyone has from the Jia Tan group – you have timings on packets.
The most immediate thing you can do there – with a nod to Cliff Stoll’s own estimate to locate the other end of a connection – is put at least an upper bound and likely a rough distance that the packets are traveling, by looking at the minimum latency.
But…I bet that you can do more. If you’re logging congestion on major Internet arteries, I’d imagine that it shouldn’t take too many instances of latency spikes before you have a signature giving the very rough location of someone.
Some other people pointed out that if they used a browser, it may have exposed some information that might have been logged, like encodings.
I don’t foresee anyone with the kind of data needed to do more investigation releasing it to the public, so I doubt we’re going to be getting any satisfying answers to this. Microsoft may have an internal team combing through github logs, but if they find anything they’re unlikely to be sharing it with anyone but law enforcement agencies.
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.
Or they are Chinese, and pick non-authentic Chinese names so people wouldn’t suspect them? I don’t think looking at the name can be a great way to identify the source.
This attack is clearly sophisticate: the attacker(s) are probably well-trained in obscuring their identity to not reveal much info from their name picks. Say, just use a random name generator.
The name is suspicious because “Jia Cheong Tan” uses two different romanization of Chinese used in different regions. “Jia” and “Tan” seems to be pinyin, which is commonly used in the mainland; yet “cheong” uses probably Wade-Giles which is used in Taiwan.
OP seems to suggest cheong is Jyuping, which is used as a romanization for cantonese, but according to wikipedia, “eong” is not a final for Jyuping. So I don’t think this is Jyuping.
disclaimer: I don’t know a lot about Jyuping or Wade-Giles, so everything I put out is from wikipedia.
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.
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.
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.
Add comment