4 ms·

> Is it really an established idea in the security community that systemd is a security nightmare? Here's a list of systemd-specific CVEs over the years: https

> Is it really an established idea in the security community that systemd is a security nightmare? Here's a list of systemd-specific CVEs over the years: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd... Note that these apply to all programs in systemd distribution (not sure how many of these are specific to systemd init program). It seems that a lot of criticism is due systemd doing more than a classic init process does, but some of it seem unjustified since you it is not an "all or nothing" package. For example, this specific CVE affected systemd-resolved (systemd's DNS daemon), but IIRC Debian was not affected since it did not use systemd-resolved by default: https://www.cvedetails.com/cve/CVE-2017-15908/ https://www.cvedetails.com/cve/CVE-2017-15908/ So it is perfectly fine for a distribution use systemd init system but use other network daemons.

Karunamon 6y ago
>>It seems that a lot of criticism is due systemd doing more than a classic init process does, but some of it seem unjustified since you it is not an "all or nothing" package. I hate this argument because, in practice, it is an "all-or-nothing" package from a user standpoint. Packages have a terrible habit of setting dependencies on one or two of the "modules," which wind up bringing the whole thing along with them. Sure, you can "disable" it after the fact, but then you're left with a system that will break in fun and exciting ways when something a package you requested wants isn't available. If you don't want systemd, your only option at this point is also-ran distros.
- Spivak 6y ago
  systemd is extremely modular if you’re the one compiling it (i.e. you’re a distro-builder) but not as an end-user since it’s used as the plumbing for your distro. And since distros aren’t usually in the business of telling users not to use features they ship everything because someone might want it.
zorked 6y ago
The fact that systemd bundles a lot of functionality (which is different from being a monolith) means it has a disadvantage in the terrible metric of "CVE counts". Now if only the systemd-hating crowd would take a look at how many CVEs affected their DHCP client, nscd, nss and other resolvers, various PAM modules, syslog/klogd, ad-hoc init scripts writing insecurely to /tmp, ntpd, etc.

Karunamon 6y ago

>>It seems that a lot of criticism is due systemd doing more than a classic init process does, but some of it seem unjustified since you it is not an "all or nothing" package. I hate this argument because, in practice, it is an "all-or-nothing" package from a user standpoint. Packages have a terrible habit of setting dependencies on one or two of the "modules," which wind up bringing the whole thing along with them. Sure, you can "disable" it after the fact, but then you're left with a system that will break in fun and exciting ways when something a package you requested wants isn't available. If you don't want systemd, your only option at this point is also-ran distros.

Spivak 6y ago
systemd is extremely modular if you’re the one compiling it (i.e. you’re a distro-builder) but not as an end-user since it’s used as the plumbing for your distro. And since distros aren’t usually in the business of telling users not to use features they ship everything because someone might want it.

zorked 6y ago

The fact that systemd bundles a lot of functionality (which is different from being a monolith) means it has a disadvantage in the terrible metric of "CVE counts". Now if only the systemd-hating crowd would take a look at how many CVEs affected their DHCP client, nscd, nss and other resolvers, various PAM modules, syslog/klogd, ad-hoc init scripts writing insecurely to /tmp, ntpd, etc.