Remove need for libc6-dev on known linux runtimes

[tkp1n]

The current mechanism to dynamically load the PKCS#11 library on Linux (and macOS) requires libc6-dev to be installed on the target systems. It also requires the methods dlopen & co to be present in the libld library.

On some linux flavors (e.g. Ubuntu 22.04) dlopen & co were moved from libld to libc. Other systems may not have libc6-dev installed at all.

This PR proposes to leverage the runtimes packaging of the required functions to mitigate those (potential) issues. The solution is inspired by the dynamic loading implementation of the grpc library found here: https://github.com/grpc/grpc/blob/be80a7047bc5a2be19b994756060fda4d779d141/src/csharp/Grpc.Core/Internal/UnmanagedLibrary.cs

Merging this PR would allow the usage of the Pkcs#11Interop library on Ubuntu 22.04 and other linux flavors with atypical placement of the functions required to dynamically load libraries.

[tkp1n]

Related discussion: #168

[jariq]

The current mechanism to dynamically load the PKCS#11 library on Linux (and macOS) requires libc6-dev to be installed on the target systems. It also requires the methods dlopen & co to be present in the libld library.

This is not true.

It is true that Pkcs11Interop uses [DllImport("libdl"... attribute to resolve dlopen, dlclose, dlsym and dlerror unmanaged functions on non-windows platforms but that does not necessarily mean there needs to be libdl.so/libdl.dylib present on the system (that's just the default behavior). In reality "libdl" is an arbitrary string/alias that can be translated to whatever the target system needs.

In older versions of Mono runtime dllmap entry could be added to app.config in order to map "libdl" to anything else. See app.config present in Pkcs11Interop repository for an example.

In newer versions of .NET Core runtime DllImportResolver delegate can be used with NativeLibrary.SetDllImportResolver method in order to map "libdl" to anything else. Sample can be seen in #168 (comment) or in Pkcs11LoggerTests project.

Merging this PR would allow the usage of the Pkcs#11Interop library on Ubuntu 22.04 and other linux flavors with atypical placement of the functions required to dynamically load libraries.

That is true but only partially.

This PR for example uses [DllImport("libcoreclr"... attribute instead of [DllImport("libdl"... attribute. It might currently work with .NET 6 on Ubuntu 22.04 without the need for DllImportResolver but it might not work on other distributions where libcoreclr.so is named differently. So on other distributions (or even on Ubuntu few releases later) this might end up with DllImportResolver that will translate "libcoreclr" to some other string.

Moreover I personally don't believe it is a best idea to resolve dlopen, dlclose, dlsym and dlerror functions with libcoreclr.so because that library does not export dl* functions, it just depends on them (see nm -D /usr/share/dotnet/.../libcoreclr.so | grep dl and man nm for more details). But if you believe it is a good idea then you can simply add DllImportResolver to your app and make it translate "libdl" to "libcoreclr". I will not add sample code here to prevent people from copying it.

To sum up my current opinion:

I'm not currently keen to merge this PR but I see that we need to better document how to use Pkcs11Interop on non-windows systems. As a result I plan to:

• Add DllImportResolver to GETTING_STARTED sample
• Move CI testing from Ubuntu 20.04 to 22.04 and modify Pkcs11Interop.Tests accordingly

I am of course open to read more detailed reasoning for this PR and change my mind if needed 👍🏻

[tkp1n]

Thanks for your information. I was unaware of DllImportResolver. A sample in the documentation would do the trick. Closing this PR.