Re:Excellent succinct breakdown of the xz mess, from an Open...
by zokier on Friday April 05, 2024 @01:27PM
(#39944929)
> But obviously you need a library to implement actually speaking system's protocol
That is overstatement. The docs have basic self-contained example how to implement the notification without libraries, its 50 lines, majority of which is just error handling:
https://www.freedesktop.org/software/systemd/man/devel/sd_no...
Re:Excellent succinct breakdown of the xz mess, from an Open...
by NekkoDroid on Friday April 05, 2024 @01:46PM
(#39945129)
The example was only recently added (like 1-2 days ago). Before that it was only really explained and said it was stable (and guarnteed as stable API).
Re:Excellent succinct breakdown of the xz mess, from an Open...
by logicprog on Friday April 05, 2024 @04:50PM
(#39947052)
Oh, cool! I was just trying to give the maximum benefit of the doubt, but this is good to know. The systemd hate never seems as justified as it'd like to be...
Re:Excellent succinct breakdown of the xz mess, from an Open...
by o11c on Friday April 05, 2024 @12:49PM
(#39944563)
> even though there are at least two other libraries that implement just the communication functionality and are actually designed for non-systemd programs to use.
The important question is: if one of those libraries is used, and then something else pulls in `libsystemd`, will they conflict?
Re:Excellent succinct breakdown of the xz mess, from an Open...
by zokier on Friday April 05, 2024 @01:28PM
(#39944943)
Why would they? There isn't any magic in libsystemd, its just a normal c lib
Re:Excellent succinct breakdown of the xz mess, from an Open...
by o11c on Friday April 05, 2024 @10:20PM
(#39949474)
A lot of systemd-replacement shims try to be transparent, which means exporting the same symbols as the real systemd libs and thus causing weird conflicts if you link to the real systemd libs too.
If I recall correctly based on what I've read about this — I believe from the original mailing list post that noticed the vulnerability — it's because under certain circumstances in order to enable certain functionality you might want sshd to be able to talk to systemd, so distros often patch sshd with code to do that. But obviously you need a library to implement actually speaking system's protocol, and as it happens, the easiest way to do that is to include the entirety of libsystemd, since it has functions for doing that, even though there are at least two other libraries that implement just the communication functionality and are actually designed for non-systemd programs to use. The problem with that idea being that libsystemd, being a whole standard library for all systemd-related functionality that is probably mostly designed for use by programs in the tightly integrated systemd family and as a reference imenentation, also includes a lot of other code, including code that has to deal with compression that depends on liblzma, even though all of that is never used by sshd, because it only uses the small subsection of the library it needs.