Poettering seems to have offered a solution that doesn't break existing installs, but only after the maintainer had already thrown up his hands in frustration.
Huh, so someone broke behavior and decided users were wrong rather than fixing it? :-/
I get maintaining API can be hard[1], but system service devs need to recognize that it’s much more important to maintain shipped API than ideological purity, certainly you can improve the API, but unless an API is actually broken in some way that can’t be automatically worked around it needs to be maintained [2].
Aside from anything else, making installation of updates break user’s systems discouraged installing updates. Including critical security ones. (An example of the terrible security impact of functionally user hostile updates can be found in windows 10)
[1] I’ve worked on frameworks with strict ABI compatibility requirements which easily dwarfs the problems of maintains API, and have had to do exciting things to make sure such things continue to work. Another example was back in the early days of .net MS added support for a not quite standardized decimal format. It was used and stored in many projects and applications, but the final spec changed slightly. MS knew it couldn’t break existing data (which is what the effect of adopting the final standard would do), and they were trying to standardize .net so I assume that prevented any kind of defacto standard behaviour. In the end someone at IBM (I think) worked out a way to distinguish the two formats just from the structure of the data. So when people say Maintaining api compat is too hard it annoys me a lot.
I mean it seems like the solution was accepted after someone suggested it. Can't fault someone for not offering a perfect solution when they didn't think of it.
"Revert the code to preserve the previous behavior" is bad because the design is wrong and will be surprising to someone else in two months.
"Fix the behavior" is bad because it breaks existing configuration that relied on the broken design.
The systemd devs seem to, as a matter of philosophy, prefer breaking things in order to do things right so I think anyone who pays attention to the mailing lists would have called the initial decision from the beginning.
"To the best of our knowledge, all systemd-based Linux distributions are
vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora
28 and 29 are not exploitable because their user space is compiled with
GCC's -fstack-clash-protection."
Interesting. Maybe it's time I switched from Debian to Fedora...
This is mostly just a matter of release cycles, where Debian's is slow and the timing is unfortunate for them. Had this been discovered a few months from now (after the release of Debian 10, which has a modern-enough GCC version for -fstack-clash-protection), it also wouldn't have been vulnerable.
Fedora takes security very seriously and I adore the distro in part for being on the bleeding edge, but this has more to do with where these distros happen to be in their release cycles than how seriously they take security.
I'm sure he has his reasons but the thread doesn't seem to illuminate anything.
They were creating a new service to archive the persistent storage in the kernel which was modeled similarly to crash dumps and then prototyped as a shell script. There was a suggestion to turn the script into something written in C so that it wouldn't depend on the existence of a shell and have better reporting. And then just out of the blue "I'm done" with very little context. There's really nothing particularly juicy I can find leading up to the announcement. Like I wonder what the final straw was.
I mean there are the recent CVEs, but those are bugs that were caught and fixed -- very little software would stand up to that level of scrutiny. Where is the crazyness?
10 comments
[ 2.9 ms ] story [ 33.9 ms ] threadI thought Debian wasn't affected? Maybe I'm missing something.
https://github.com/systemd/systemd/issues/11436
Poettering seems to have offered a solution that doesn't break existing installs, but only after the maintainer had already thrown up his hands in frustration.
I get maintaining API can be hard[1], but system service devs need to recognize that it’s much more important to maintain shipped API than ideological purity, certainly you can improve the API, but unless an API is actually broken in some way that can’t be automatically worked around it needs to be maintained [2].
Aside from anything else, making installation of updates break user’s systems discouraged installing updates. Including critical security ones. (An example of the terrible security impact of functionally user hostile updates can be found in windows 10)
[1] I’ve worked on frameworks with strict ABI compatibility requirements which easily dwarfs the problems of maintains API, and have had to do exciting things to make sure such things continue to work. Another example was back in the early days of .net MS added support for a not quite standardized decimal format. It was used and stored in many projects and applications, but the final spec changed slightly. MS knew it couldn’t break existing data (which is what the effect of adopting the final standard would do), and they were trying to standardize .net so I assume that prevented any kind of defacto standard behaviour. In the end someone at IBM (I think) worked out a way to distinguish the two formats just from the structure of the data. So when people say Maintaining api compat is too hard it annoys me a lot.
[2] Linux kernel devs recognize this as well.
"Revert the code to preserve the previous behavior" is bad because the design is wrong and will be surprising to someone else in two months.
"Fix the behavior" is bad because it breaks existing configuration that relied on the broken design.
The systemd devs seem to, as a matter of philosophy, prefer breaking things in order to do things right so I think anyone who pays attention to the mailing lists would have called the initial decision from the beginning.
Interesting. Maybe it's time I switched from Debian to Fedora...
Fedora takes security very seriously and I adore the distro in part for being on the bleeding edge, but this has more to do with where these distros happen to be in their release cycles than how seriously they take security.
No one who wants to maintain control over their machine should use this software. We should honestly just consider it a rootkit at this point.
They were creating a new service to archive the persistent storage in the kernel which was modeled similarly to crash dumps and then prototyped as a shell script. There was a suggestion to turn the script into something written in C so that it wouldn't depend on the existence of a shell and have better reporting. And then just out of the blue "I'm done" with very little context. There's really nothing particularly juicy I can find leading up to the announcement. Like I wonder what the final straw was.
I mean there are the recent CVEs, but those are bugs that were caught and fixed -- very little software would stand up to that level of scrutiny. Where is the crazyness?