It's kind of amazing that systemd had already upstream changed the behaviour of libsystemd such that liblzma wouldn't have been loaded, raising the hilarious possible alternative reality where that release got cut earlier and hit distros before the backdoored liblzma did and all of that work would have been for nothing
@mjg59 I read that Fedora ended up loading liblzma into sshd via libselinux too?
@mjg59 ....which kinda suggests that something like this may well have happened before and we never found out about it lol
@mjg59 OK, so we can spin this as systemd not caring about API compatibility, which is bad, on top of systemd trying to do far too much. which is also bad
@DrHyde "My backdoor relies on this behaviour, please revert this change to maintain ABI"
@DrHyde @mjg59 Where did you get that from?

@mjg59 There was also a point made in oss-security that open coding a simple (and stable) function would have avoided these library dependencies: https://www.openwall.com/lists/oss-security/2024/03/29/27

IMHO it's too easy to add external dependencies to code these days, and self-contained code is underrated.

oss-security - Re: backdoor in upstream xz/liblzma leading to ssh server compromise

@mjg59 This might explain the weird times of day at the end of Jia Tan's commit history