This reads as though your objection is to the scope of systemd rather than its implementation detail, which isn’t where my objection lies.
I have nothing against the service management stack also addressing common principles like logging and on-demand starts a la inetd, but the notion that applications should link against a component of the service manager which is also used by the service manager boggles my tiny mind.
I have never seen anybody point to it as a security risk before this happened. Would be happy to see a reference of somebody saying that prior to the xz event
Comments
That is the systemd way, and what many of us have pointed out for years as a major risk of the approach.
This reads as though your objection is to the scope of systemd rather than its implementation detail, which isn’t where my objection lies.
I have nothing against the service management stack also addressing common principles like logging and on-demand starts a la inetd, but the notion that applications should link against a component of the service manager which is also used by the service manager boggles my tiny mind.
libsystemd is not being used by systemd itself.
I have never seen anybody point to it as a security risk before this happened. Would be happy to see a reference of somebody saying that prior to the xz event
Report is that shortly before the hole was reported, a PR had been posted requesting to remove the dependency on xz.