LZMA is a widely used compression protocol. The kernel uses it. xz - the compression tool that was affected gets used by the kernel build makefiles - they reference it in the build docs https://docs.kernel.org/staging/xz.html. It's absolutely fair from systemd to have this dependency and to use the trusted library that the most fundamental part of the underlying OS uses.
It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.
Your speculation on what is right and what was fair is of no consequence to me. Their error was not simply using a compression library, it was creating a large central point of failure. If Systemd was smaller, it would not have caused this error. By being large, it made itself vulnerable. It made itself a target. It made other software insecure. These facts are inescapable. And you cannot justify this by simply saying they didn't do anything wrong right before the attack, or that packagers are to blame, or that other software might also be vulnerable, or anything else that doesn't address the core of the issue: Systemd created the circumstances needed for this to happen. They were warned of he risks they created, and chose to do so anyway. Now those risks have been made manifest – the inevitable result of a fundamentally flawed design.
Why is this an argument specifically against systemd, rather than all large software projects?
Linux kernel, gcc, glibc - all bundle "a large amount of functionality under a single system" - does this make their design fundamentally flawed as well?
I think a micro-kernel architecture would be better in many ways, security being just one of them. With GCC, it couldn't really be separated into logically distinct modules any more than it already is. All of the constituent parts essentially use the full functionality of the base compiler part, so there is little to be gained separating them. It's not as if the C compiler from GCC, could for instance, be written in such a way that it doesn't depend on GCC. GLibc is a large implementation, but the library itself doesn't necessarily need to be large. There are some very small libcs out there.
On the whole, I do not like monolithic software projects, but I can accept that they are necessary or beneficial in some cases. Systemd is simply a much bigger target than these other things because it is an especially bad example. It has many components which are only tentatively connected. It is also more fixable. Alternate init systems are used much more widely than something like Hurd to replace Linux. The laptop I'm typing this from runs GuixSD which ships without Systemd and I can hardly notice the difference. I doubt a different kernel architecture would provide such a seamless experience.
Given how common LZMA as a compression algorithm is, are you certain that your init system of choice doesn’t use it in any way? It’s a very common algorithm in network protocols, it’s a direct dependency of libxml, … - and if any part of your init system uses LZMA, then it just happens not to be affected because the attacker chose to target one specific system.
The attacker had essentially full control over a very fundamental library in the Linux ecosystem. They could have leveraged that in a hundred ways.
The attacker chose to target a very specific component of a very specific system. It was their choice, not some sort of technical requirement that made it impossible to use a different attack vector. Just as they chose not to target other Linux distributions that use systemd.
You’re essentially saying “I was safe because the attacker chose to ignore me.” That worked well this time, but it’s a pretty dangerous stance.
When a hacker chooses to attack something, that isn't random. They had to look at a lot of different pieces of software, and decide which would be the best to attack. The choice in this case was Systemd. In other words, if you are looking to do malicious things, Systemd is helpful.
Now I want you to imagine that every piece of software has a score, which tells you how useful it is to hackers. Systemd has a high score, and hence it was chosen for this attack. Your argument is that: there are other pieces of software with a high score so it's fine for Systemd to also have one, since without it there would be other things to attack. My argument is that we should reduce the amount of software that has a high score. Do you think my reasoning or your reasoning will lead to a more secure ecosystem?
It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.