as I explain in my blog, the real problem is libraries which are large amalgamations of unrelated routines, such as libsystemd in the case of CVE-2024-3094.

a good solution is to split up these giant libraries into smaller ones, thus allowing for the dependency graphs of programs to remain leaner.

there is nothing about sd_notify() which requires LZMA compression. nothing. it is a function which writes a supplied string to a UNIX socket, the path of which is provided on an environmental variable.

@ariadne "Let Unix be Unix" ... Is the catchphrase I came up with yesterday. I have some thoughts around it, but they have yet to coalesce into an article. Needless to say, part of it was that systemd does not follow this philosophy.
@drj to be absolutely clear, while i point to libsystemd as being a key part of the exploitation chain for this xz backdoor, i am really uninterested in hearing random pet arguments on systemd not being UNIX enough. the horse is beaten, it is not just dying, it is entirely dead at this point.
@ariadne @drj not just that but the irony is that half of how the backdoor was so easy to hide in the build scripts is because of the tools purists would love to consider peak unix philosophy

@asu I think you might have confused GNU with Unix, because i don't consider m4 and autotools as part of "Let Unix be Unix". I don't disagree with you on the irony though; i'm just not sure which way it goes. 😂

Who whole thing _looks_ like it was "fortuitous" (that xz used m4 for example, or that systemd injects lzma into sshd), but actually it's the result of what was presumably quite a careful hunt for a set of tools with just the right injectable properties.