On Fr, 10.12.21 10:40, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
On 10/12/2021 08:34, Zbigniew Jędrzejewski-Szmek wrote:
We also changed various libraries to be dlopened when actually used, instead of being dynamically linked. The goal is to reduce the required dependencies.
What happens if these libraries are not installed an cannot be dl-opened?
We handle that gracefully. i.e. the specific feature is disabled, but everything else stil works as it should.
here's an example: systemd-cryptenroll allows you to enroll additional keys into LUKS2 volumes for systemd-cryptsetup to honour. Besides pkcs11/fido2/tpm2 stuff it also supports "recovery keys", which are pretty much the same as a regular password, but are computer generated rather than user chosen, and thus have guaranteed high entropy. Since users have to read the generated key off screen and write it down/store it away somewhere, we will normally show you a QR code in the terminal you can quickly scan it off screen with. This is implemented via dlopen()ing libqrencode. If you install that lib, you'll get the QR code + text string displayed. If not, you'll just get the text string.
And the other cases where we use dlopen() are pretty much the same: the specific feature is skipped or made unavailable, but the basic behaviour remains the same. When we really really need something, then we'll use regular share library deps as always, not dlopen(). We use dlopen() only for the stuff that isn't a "core" feature, i.e. essential for the program to do its thing.
It's an excercise in minimizing our footprint (for containers, embedded devices) , but still providing a rich feature set for those who want it, without requiring recompilation, and whith automatic upgrading to the full feature set, simply by dropping in a few more of the optional deps.
Lennart
-- Lennart Poettering, Berlin