By "code architecture" I mean the packaging of their client libraries. This attack demonstrates that they should be tightly focused and have minimal downstream

By "code architecture" I mean the packaging of their client libraries. This attack demonstrates that they should be tightly focused and have minimal downstream dependencies. I don't have any experience with systemd, but typically, people will bundle _all_ of their client libraries into one .so and say "use that". However, what needs to happen is there should be multiple .so's, one for each sub-API. At least there should be libraries for frequently used shim code (like notifications seems to be). Then systems that need to push information don't need to pull in the dependencies for other parts of the overall systemd interface. I can't think of a reason why pushing local notifications would require a compression library. The notifications should be information heavy already, so not very compressible. As I said, it's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently. How the team responds is what is important. That is why people are objecting to the SUID work. Not because sudo isn't a hole, but that the systemd team isn't considered responsive enough to take it on. I know I'm taking lessons from this to my work. It's an unpleasant mirror for me to look in.