
Debian systemd maintainer steps down - AdmiralAsshat
https://lists.freedesktop.org/archives/systemd-devel/2019-January/041971.html
======
camgunz
It's pretty shocking to see this (slightly reformatted for sanity):

    
    
        int journal_file_append_entry(JournalFile *f, const dual_timestamp *ts,
                                      const struct iovec iovec[], unsigned n_iovec,
                                      uint64_t *seqnum, Object **ret, uint64_t *offset) {
            items = alloca(sizeof(EntryItem) * MAX(1u, n_iovec));
    

Stack-allocating based on a function argument, with no checks?

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.

------
olliej
For the uninformed, what is going on that is stupid/crazy?

~~~
AdmiralAsshat
This is most likely the issue in question:

[https://github.com/systemd/systemd/issues/11436](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.

~~~
olliej
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.

[2] Linux kernel devs recognize this as well.

------
Spivak
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?

------
gt565k
"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...

~~~
ejrv
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.

