Is libressl (fully) supported instead of openssl?

[lyze237]

Hello!

I'm currently trying to install the dotnet core sdk (via it's binary package) on Void Linux which uses libressl instead of openssl.

After installing libunwind and icu the dotnet -h command works fine. However when I try to run dotnet new console I get the following error:

https://github.com/dotnet/corefx/blob/4d7ee843bf1496c0d9c01671befdeb65548aef1f/src/Native/Unix/System.Security.Cryptography.Native/opensslshim.cpp#L42

No usable version of the libssl was found
Aborted

When I symlink the existing libressl library /lib/libssl.so.43 to one of the paths in the above linked source file, e.g. /lib/libssl.so.1.0.0 everything works fine.

I've cloned a asp.net core rest api server / dotnet core rest api client solution and ran it just fine without errors.

---

Does dotnet core fully support libressl and what should the project do to detect those libraries easier/better?

[bartonjs]

No, libressl is not supported at all.

[ghost]

Could be that in some distro, libssl.so.x symlink is pointing to libressl.so? They are API compatible.

When I symlink the existing

In upcoming (2.1) release of dotnet core, we can set version as environment var as well CLR_OPENSSL_VERSION_OVERRIDE=43 dotnet build. See dotnet/corefx#27208. It could also be used if some distro has used major.minor convention for libssl.

[bartonjs]

They are (were, actually) theoretically API compatible, but not ABI compatible, meaning that you have to recompile against LibreSSL's headers to get their struct layout.

Using LibreSSL is not supported. That means that we don't test with it, and we won't fix any bugs which involve bad interactions with LibreSSL. It might work. Or it might produce wrong answers. Or it might segfault.

[ghost]

Sounds reasonable. i found some hints of LibreSSL in CoreFX sources https://github.com/dotnet/corefx/search?q=libressl and was wondering therefore.

Since build-from-source document particularly mentions openssl or libressl under dev dependencies, could the team's stance instead be slightly lenient: "use libressl at your own risk. If you (someone in community) find a bug, send a non-openssl-imp-breaking patch via PR and we will review it"? Otherwise, that document should be updated to "strictly openssl". 😄

[bartonjs]

The current (2018-09-13) references to LibreSSL in the codebase are all from System.Net.Http, where it's talking about working with libcurl backed by libressl. In particular, we're detecting that it's libressl instead of openssl (because it reported being OpenSSL due to how it got integrated into curl) so we can turn off particular features (mainly, we're avoiding sending pointers between the two libraries).

By saying that .NET Core does not support LibreSSL as a cryptography and TLS provider we're not saying "we know it to not work", we're saying "we don't test it, we don't describe it as something that works, and we won't spend time fixing bugs that are unique to changing the platform from using OpenSSL to LibreSSL".

To take that statement a bit further, I can say "using the prebuilt ('portable') System.Security.Cryptography.Native.OpenSsl.so and forcing it to load LibreSSL is dangerous". Things are probably mostly fine when using a locally built 'non-portable' version of the shim library... but see previous paragraph for if something doesn't work 😄.

could the team's stance instead be slightly lenient: "use libressl at your own risk. If you (someone in community) find a bug, send a non-openssl-imp-breaking patch via PR and we will review it"

That's a reasonable description of what "not supported" means here. But such a PR would need to be pretty well contained... a 3000 line PR to make something work/work-better/work-differently on LibreSSL would still require a significant amount of time to review, and would likely get closed by being too large of scope for a non-supported scenario.

Closing the issue since the original question ("Does dotnet core fully support libressl?") has been answered ("no").