On Sun, Mar 26, 2017 at 05:44:20AM +0200, Guillem Jover wrote: > As I've also noted in the past [B], I'd go even further and say that > we need at least to very strongly discourage, but ideally outright ban > the dlopen()ing of shared libraries that are not part of the same > source package or at least under the control of the same upstream > project, or are shared libraries that define themselves to the ABI > and SONAME level (but those are very few and rare).
This wording as written bans third-party plugins. I'm sure you didn't mean that, and meant instead something like wanting to have .so files be used *either* for dlopen() *or* for compile-time dynamic linking. Unfortunately, that too would forbid some legitimate uses. For example, the PKCS#11 standard defines an API which can be used to access cryptographic routines and is popular for accessing hardware security modules (HSMs) or smart cards. It's supported by OpenSSL (using an engine), OpenSSH (for converting RSA keys on smartcards to SSH keys), Firefox, Libreoffice, and Thunderbird, as well as various other bits of non-free software. OpenSC is one example of a package in Debian which ships a PKCS#11 module. An application would typically use the PKCS#11 module by dlopen()ing it, based on configuration related to the specific piece of hardware you're trying to use. At the same time, the API is flexible enough that it can be used by a specific implementation to export extra data beyond the cryptographic material. An application using the API in that way would probably be written for one specific device, rather than any random device, and hence it might be easier for the programmer to link to the shared object at compile time. I realize this is a bit extreme, but it's not a hypothetical scenario; the support software for the Belgian electronic ID card that I work on at $DAYJOB works in the above-described fashion. Having said that, I would agree with the general feeling that in most cases dlopen()ing random shared libraries is a bad idea; but at best, this can be specified as a SHOULD (in the RFC sense, not the Policy sense). -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12