Can OpenSSL native library be lazy loaded?

[mthalman]

I've been experimenting with Docker Slim to produce extremely slimmed down versions of .NET containers that contain only the files that are actually used by the app. After examining the results of a basic Hello World console app, I wonder whether it'd be possible to modify the runtime to further reduce its dependencies.

Here's the list of files that are left in my Alpine Linux 3.12 container after applying Docker Slim (my app is published as a single file):

FILE                                  SIZE
/app/app                              14.9M
/etc/os-release                       164B
/lib/ld-musl-x86_64.so.1              582.5K
/lib/libcom_err.so.2.1                13.6K
/lib/libcrypto.so.1.1                 2.5M
/lib/libssl.so.1.1                    511.5K
/lib/libz.so.1.2.11                   97.8K
/usr/lib/libgcc_s.so.1                73.7K
/usr/lib/libgssapi_krb5.so.2.2        280.2K
/usr/lib/libk5crypto.so.3.1           170.1K
/usr/lib/libkeyutils.so.1.9           21.7K
/usr/lib/libkrb5.so.3.3               786.5K
/usr/lib/libkrb5support.so.0.1        46.1K
/usr/lib/libstdc++.so.6.0.28          1.6M

I'm specifically wondering about the need for libssl.so.1.1. Again, I have a simple .NET 5 app (System.Console.WriteLine("Hello World!");) with, presumably, no underlying dependency on OpenSSL. The libssl.so.1.1 file is currently required however because it's loaded as part of the loading of the libSystem.Security.Cryptography.Native.OpenSsl module due to:

runtime/src/libraries/Native/Unix/System.Security.Cryptography.Native/opensslshim.c

Line 120 in e29b839

static void InitializeOpenSSLShim()

I'm wondering if it's possible to have OpenSSL lazy loaded until the point where it's required. Presumeably, that would allow my container to not require the libssl.so.1.1 file and remove 500K from it.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I've been experimenting with Docker Slim to produce extremely slimmed down versions of .NET containers that contain only the files that are actually used by the app. After examining the results of a basic Hello World console app, I wonder whether it'd be possible to modify the runtime to further reduce its dependencies.

Here's the list of files that are left in my Alpine Linux 3.12 container after applying Docker Slim (my app is published as a single file):

FILE                                  SIZE
/app/app                              14.9M
/etc/os-release                       164B
/lib/ld-musl-x86_64.so.1              582.5K
/lib/libcom_err.so.2.1                13.6K
/lib/libcrypto.so.1.1                 2.5M
/lib/libssl.so.1.1                    511.5K
/lib/libz.so.1.2.11                   97.8K
/usr/lib/libgcc_s.so.1                73.7K
/usr/lib/libgssapi_krb5.so.2.2        280.2K
/usr/lib/libk5crypto.so.3.1           170.1K
/usr/lib/libkeyutils.so.1.9           21.7K
/usr/lib/libkrb5.so.3.3               786.5K
/usr/lib/libkrb5support.so.0.1        46.1K
/usr/lib/libstdc++.so.6.0.28          1.6M

I'm specifically wondering about the need for libssl.so.1.1. Again, I have a simple .NET 5 app (System.Console.WriteLine("Hello World!");) with, presumably, no underlying dependency on OpenSSL. The libssl.so.1.1 file is currently required however because it's loaded as part of the loading of the libSystem.Security.Cryptography.Native.OpenSsl module due to:

runtime/src/libraries/Native/Unix/System.Security.Cryptography.Native/opensslshim.c

Line 120 in e29b839

static void InitializeOpenSSLShim()

I'm wondering if it's possible to have OpenSSL lazy loaded until the point where it's required. Presumeably, that would allow my container to not require the libssl.so.1.1 file and remove 500K from it.

Author:	mthalman
Assignees:	-
Labels:	area-System.Security, untriaged
Milestone:	-

[EgorBo]

It definitely should be done, related: #44505 (comment)

[wfurt]

This is already lazy-loaded for portable builds.

Compare #45720 (comment) to this:

When the libSystem.Net.Security.Native.so is build with /p:portable=true I get

furt@ubu18:~/github/wfurt-runtime/src/libraries/Native$ ldd /home/furt/github/wfurt-runtime/artifacts/bin/native/Linux-x64-Debug/./libSystem.Net.Security.Native.so
	linux-vdso.so.1 (0x00007ffdfc65c000)
	libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007ff6160c3000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff615cd2000)
	libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007ff6159fc000)
	libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007ff6157ca000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007ff6155c6000)
	libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007ff6153bb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff616513000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007ff6151b7000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007ff614f9c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff614d7d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff614b79000)

That still sucks in all the kerberos but direct dependency on OpenSSL is gone.

While this may be interesting for HelloWorld demo, I'm wondering how many really apps in practice can live without from of secure communication e.g. without crypto and TLS.

Static linking can save on the base image but it will suck all that into each app MHO once needed.

[bartonjs]

This is already lazy-loaded for portable builds.

It used to be the case that Alpine used LibreSSL instead of OpenSSL, and so we only supported "strongly dynamic" (normal DLL/SO) compilation. But since they've switched back to OpenSSL we could probably go back to using portable builds there. I'm not sure where in our universe that lives.

[am11]

we could probably go back to using portable builds there.

I am happily using linux-musl dotnet binaries with libressl on Void Linux (musl-flavor) x64 since 04b67d3. In fact, in our current build matrix, everything is portable=true in this repo.

Only place (that I know of) that has portable=false is dotnet/source-build.

[VSadov]

I will need to make this lazy-loaded at least on macOS.
Eager-loading of OpenSSL is blocking for the singlefile scenario. See #46771

[gsmachado]

@VSadov any news on this issue (and #45720)? Since #46771 seems to be "solved"...

[bartonjs]

It's not clear that there's any work remaining here (at least for the assigned area), and there hasn't been any activity in a long while; so assuming this is no longer an area of concern.