I don't understand the initial motivation for converting regular dynamic library dependencies to dlopen dependencies. How does that help with reducing the footprint?
Which the recent xz attack used to mess with `sshd`, even if it never actually used functions from the library.
dlopen loading only loads the library *when it's actually used*, and doesn't include everything and the kitchen sink on startup.
If the libraries are used seldomly enough, it might also allow to make more dependencies optional in package management.
What you gain is that the vulnerabilities will be harder to track down?
Debian's sshd only uses libsystemd for the notify api. I.e. it doesn't need any feature that uses libxz. If it's dlopen()ed, it does not need to be loaded into the process context to use an unrelated feature.
FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX.
FWIW, upstream systemd has the opinion that no-one should load the library for startup notification, instead they should use the well documented api and just write a message to a socket.
It calls it a "good choice". Did they say somewhere else that no-one should do it despite it supposedly being a good choice?
They've done the exact opposite afaict. Libsysd used to be split up, now it is monolithic.
They probably couldn't change it anymore if they tried to.
No, they're just as easily tracked.
What you gain is that you can refuse to install optional dependencies because they are now optional when they used to be required.
That's a fairly big deal.
Of course, in practice all those optional dependencies will be installed anyways because of other things in the distro needing them. You can fairly object that not much changed, at least for now.
A better approach would be to eliminate a lot of these dependencies somehow. Another approach would be to sandbox the dependencies that cannot be eliminated.