What we need to take away from the XZ Backdoor (openSUSE News)

Attacking open-source this way is a high-risk, high-reward strategy. Sure, if you could backdoor ssh you'd be all set, but the evidence would be in public view for all time. All it takes is one person to stumble across it. There's no way to ever remove the backdoor from history. If it were really that common, we'd see the evidence all over the place. And we don't. This attack was found precisely because the source was publically available.

Add to the fact that the TLAs and their respective governments also use open-source software everywhere, so they'd be building backdoors into their own systems. (I'm guessing the targetting of DEB and RPM was to avoid custom government distributions being affected.)

On the other hand, backdooring closed-source software is much lower risk. The number of people who would ever see the code is much lower. When a product reaches end of life the code simply vanishes. Insert a backdoor in an NVidia/Broadcom/Dell driver, who would ever find out?

So sure, open-source developers and maintainers need to get better at vetting, but it's the corporations where the risk is. And I guess the tools to discover these kinds of attacks are also going to be developed as open-source because there's no direct benefit to any individual corporation. And how could you trust a closed source vetting tool not to be backdoored itself?

It's important to note you cannot know this. It's a counterfactual. We don't live in the world where Andres didn't find the issue, so we don't know what would have happened next. Perhaps what would have happened next is somebody else would have found it half an hour later. Perhaps not. We don't *know*. You can't say you know that "the malicious code would still be there. Jian Tan would still be working its tendrils..." etc.

Like I see nothing at all done wrong here by Debian, you just came barking up the wrong tree.

I regularly do the same thing with chromium. I package it, but it's a complex piece of software with lots of things I've never used/touched. When someone reports a bug about their screenreader not working properly with it, I request they submit it upstream. If they can't, I'll do it for them, but I've never even used a screenreader. If upstream asks me any questions about the desktop environment, or how to reproduce the bug, I can't tell them. Instead, I'll just pass the message along to the bug reporter. That's silly, and introduces lag (and maybe I'm busy filing taxes and forget to forward the email). Similarly, I've never used widevine or done chromecasting, so I'm going to send those reporters upstream as well.

No, it is not.

Moreover, given that OpenSSH uses the model of first starting to listen for the connection and then forking the systemd notification support can be implemented without touching OpenSSH using other notification mechanisms that systemd supported and that were used prior notify changes.

So refusion of OpenSSH to include the changes were rather reasonable and was strong indication that the changes were problematic.

Until the next upstream release, which will finally include the functionality natively, to be fair. It only took a world-ending supply chain attack to get that 8-years-old patch merged. Now if we just could get Jia Tan to compromise another dependency of openssh, maybe we could get the socket activation patch merged too :-)

Sounds to me more like a deficiency of systemd than one of OpenSSH ... SCNR! Notwithstanding this, if OpenSSH now has decided that they will perform the integration and take care of it in the log run, Kudos to them. It needs to be done. If i would have to guess, i'd say Linux with systemd is the most frequent environment OpenSSH is run in.

I hope that other such controversies do not require (let me quote another post here) "a world-ending supply-chain attack" to be resolved. Please, everyone, be more cooperative.

I agree with you, but just wanted to clarify some points. AIUI the patch included by upstream is not the patch distributions used. Two different patches for the same problem.

The distribution patch was adding a single line of code plus some autoconf magic to configure it. For packagers this is the obvious choice since they don't necessarily understand all the code and it's a minimal "obviously correct" patch.

The patch applied by upstream [1] avoids linking an external library and vendors the sd_notify() function, tweaking it for the OpenSSH code base. Both the distribution patch and a version of this patch were offered to the OpenSSH developers in 2018, and rejected. This patch is much larger and not as "obviously correct" so given a choice, packagers are going to go for the short patch if they get a choice.

[1] https://github.com/openssh/openssh-portable/commit/08f579...

It's interesting to compare this to the Linux kernel. There there is social pressure to not have external patches and to upstream everything. There are all sorts of good reasons for this. But the flip-side is that the kernel developers have to not randomly stand in the way of feature requests just because they don't care about the use-cases. The OpenSSH developers have opinions about the use-cases (e.g. socket activation) but also want to discourage downstream users from patching. You can't have it both ways.

As a result of this illegal wiretapping, a Greek manager in Vodafone died. Either by suicide or murder.

And the solution is the same as with all those other industries. Is your widget safety critical? Then it needs to follow verified 3rd party certified testing. That's done through legislation.

That's also the reason why Americans don't like "legislation" as a solution: they have been under 40 years of constant propaganda telling them how "the gubbement" doesn't work, paid for by the very companies that want to make stuff as cheaply as possible because next quarter financial results are the only thing that matters. Boeing is the poster child of that approach.