Re: libsystemd dependencies

Bruno Haible wrote:
> Jacob Bachmeyer wrote:
>   
>> some of the blame for this needs to fall on the 
>> systemd maintainers and their "katamari" architecture.  There is no good 
>> reason for notifications of daemon startup to pull in liblzma, but using 
>> libsystemd for that purpose does exactly that, and ended up getting 
>> xz-utils targeted as a means of getting to sshd without the OpenSSH 
>> maintainers noticing.
>>     
>
> The systemd people are working on reducing the libsystemd dependencies:
> https://github.com/systemd/systemd/issues/32028
>
> However, the question remains unanswered why it needs 3 different
> compression libraries (liblzma, libzstd, and liblz4). Why would one
> not suffice?
>   

 From reading other discussions, the only reason libsystemd pulls in 
compression libraries at all is its "katamari" architecture:  the 
systemd journal can be optionally compressed with any of those 
algorithms, and the support for reading the journal (which libsystemd 
also provides) therefore requires support for all of them.  No, sshd 
(even with the distribution patches at issue) does /not/ use that 
support whatsoever.

Better design would split libsystemd into separate libraries:  
libsystemd-notify, libsystemd-journal, etc.  I suspect that there are 
more logically distinct modules that have been "katamaried" into one 
excessively large library.  The C runtime library has an excuse for 
being such an agglomeration, but also note that libc has *zero* hard 
external dependencies.  You can ridicule NSS if you like, but NSS 
modules are only loaded if NSS is used.  (To be fair, sshd almost 
certainly /does/ use functions provided by NSS.)  The systemd developers 
do not have that excuse, and their library *has* external dependencies.

I believe the systemd developers cite convenience as justification for 
the practice, because apparently figuring out which libraries (out of a 
set partitioned based on functionality) you need to link is "too hard" 
for developers these days.  (Perhaps that is the real reason they want 
to replace X11?)  That "convenience" nearly got all servers on the 
Internet running the major distributions backdoored with critical 
severity and we do not yet know exactly what the backdoor blob did.  The 
preliminary reports that it was an RCE backdoor that would pass commands 
smuggled in public key material in SSH certificates to system(3) (as 
root of course, since that is sshd's context at that stage) are 
inconsistent with the slowdown that caused the backdoor to be 
discovered.  I doubt that SSH logins were using that code path, and the 
SSH scanning botnets almost certainly are not presenting certificates, 
yet it apparently (reports have been unclear on this point) was the 
botnet scanning traffic that led to the discovery of sshd wasting 
considerable CPU time in liblzma...

I am waiting for the proverbial other shoe to drop on that one.


-- Jacob