[kevin_thibedeau]

After his foolish use of alloca() in systemd was revealed, it's clear that the derision is well deserved. One would think that after cutting his teeth on PulseAudio he'd have learned how to write safe, system level C.

[temac]

There is even more depth to the alloca() fiasco than most people realize.

cppcheck could detect the bug without any hard setup effort (launching it in systemd codebase, with maybe an option to activate all checks, was enough) at least 2 years before it was revealed (probably more like at least 3 or 4, I don't remember the exact value). That's a fact easy to verify.

I suspect other tools could find it too, though I have not checked.

What that implies is more speculative, but there are some kind of "either or" situations that are extremely nasty. For example either RH (and all the other distro using it) did not analyse it, or they hid it for other reasons. The most reasonable hypothesis is that they just did not analyzed it. Which put them at least 15 years behind MS in some domains that were even more critical at the time (and still today) than 15 years before.

[Avamander]

Please, it's not like any single other component in Linux desktop is somehow more secure. If anything, most stuff on Linux desktops are majorly more buggier and unsafe, they're just less popular in most cases.

[kevin_thibedeau]

Desktop code can be expected to fail sometimes. Core system components that orchestrate everything, should not. Ever. This requires disciplined programming that doesn't assume the stack is a limitless resource free to abuse and fill with tainted data.

[Avamander]

Even Linux kernel has had tons and tons of vulnerabilities and bugs. Not to mention non-systemd core system components and services have been found exploitable times and times again. You can't set higher standards for systemd than other core pieces of software, it's simply not fair.

[kevin_thibedeau]

The Linux kernel has high standards. Most of the bugs come from the drivers. If systemd wants to be the end all be all init replacement it should have known from the start that it needed to meet a high bar of code quality.

[pjmlp]

This set of Google talks prove how much those "high standards" really mean in reality.

https://www.youtube.com/watch?v=XfNt6MsLj0E&list=PLbzoR-pLrL...

Pay specially attention to "Making C Less Dangerous", "STACKLEAK: A Long Way to the Linux Kernel Mainline", "Sub-system Update: Kernel Self-Protection Project", "Year in Review: Android Kernel Security", "Sub-system Update: Linux Integrity Status Update", "Security Module Stacks that Don't Fall Over ".

[Avamander]

It has high standards but the track record shows that standards isn't all it takes. We can always blame some subcomponent under someone else's control but the end result matters more.

If you want to systemd to adhere to really high standards then you're a hypocrite if you don't apply the same standards to every subcomponent of a non-systemd system, be it upstart, logrotated, cron, chrony or whatever else.

But it seems to me that you actually don't apply the same standards to the alternatives, they've all been hit with some vunerabilities, they all have bugs, they all have at least some terrible code, some lack maintenance or are just outdated. I wouldn't start throwing rocks from a glass house.

Oh and let's not forget that based on a pure empirical observation of the Linux ecosystem we can see that it is a better choice. And no, noone has been forced to use it(, neither was anyone forced to use Pulseaudio).

[craigsmansion]

> standards isn't all it takes

Obviously, since djb's daemon tools isn't used by default, which is exactly the sort of software that would be used by people who would rely on such functionality.

> It has high standards

One of SystemD's core contributers was banned from contributing to Linus' tree because his code was sub-standard.

> based on a pure empirical observation

...we should then also be able to see the Microsoft Windows operating system is a better choice.