This is supposed to be what services such as Tidelift provide - companies pay them, and OSS maintainers sign up with them for funding (and other support? unsure). But it's tough to apply this through the whole OSS ecosystem. To me, this should be what Canonical's support contracts should be for. They're perfectly positioned to help mediate these types of issues.
It's worth noting that vanilla upstream OpenSSH DOESN'T depend on xz. The dependency was patched in by the major distros to better integrate with systemd - and it's (AIUI) a transitive dependency from systemd - even the patch doesn't use it, but it gets pulled in with other systemd stuff.
that's what i believed as well, but i didn't take time to verify. and i didn't know about the details. thanks. as you describe it ssh still doesn't depend on xz (and why would it?) so part of the problem here is software architecture.
how is it possible that a seemingly unrelated dependency somewhere within systemd can affect and be exploited through ssh directly?
shouldn't it be possible to keep that separate?
doesn't openssh itself already implement some form of privilege separation?
how does software architecture here and in general need to change to prevent things like this?
i am sure somewhere these questions are already being discussed. i'd appreciate any pointers.
that's the critical question here. it's not that enterprises need to take over maintenance of xz, but that the critical packages and their dependencies need to be audited on a regular basis. the development of xz is ok. what it needs is help with code reviews. and if it can't receive those, then it needs to be removed as a dependency of openssh.
I don’t remember the company names, but I guess people will remember the incidents.
- Solarwinds have been breached end to end.
- A company has been bribed (forced?) to ship backdoored encryption algorithms.
- A network hardware supplier’s firmware had been backdoored by Chinese IIRC.
- NSA backdoored national standards.
- Microsoft has been breached end to end.
In short, even if you’re a company, you’re one NSL, one bad actor, one misstep away from “total pwnage”.
I trust some individuals for developing critical software than entire “enterprise”s.
Everything is as strong as their weakest link.
Using standard libraries for common stuff like compression, cryptography and whatnot is vastly more preferable over everyone shipping their own crypto, or worse, patches of crypto (see the Debian SSH key vulnerability of 2008 for an example [1]). For protocols it's in the end just as bad, it's a nightmare to keep different versions of the same program to be able to talk to each other, but now imagine a literal ton of programs who all have a wild mixture of statically shipped libraries, homegrown stuff that has barely been tested... no, just no. Not a world I'd like to live in.
Why is it unreasonable?
I actually see it as very reasonable. You use a package in a commercial distribution, you use aggregators like Github sponsors to pay the maintainer (a subscription, not a one-off payment!). What's unreasonable about that?
Paying the maintainers is nice, but I think the megacorps and governments has to fund an organization that does security audits of all the sensitive packages, instead of heaping yet another job on the shoulders of the maintainers. It's especially important to not saddle the developers of open source with red tape, most of them would think that getting paid is poor compensation for the lost freedom.
