lang/dotnet: Add experimental LibreSSL patch

[zirias]

Summary

Upstream source does not support LibreSSL. It can be patched to build
with LibreSSL, but this requires disabling some functions and also
interfers with the runtime OpenSSL version detection.

Therefore add a port option LIBRESSL for this, marked as experimental
and explained in pkg-descr. Mark the port as broken with
SSL_DEFAULT=libressl when this option is not set.

[arrowd]

lang/dotnet/pkg-descr

10

What's the point in adding LibreSSL support then if consequences are that serious?

Maybe start working out something directly with upstream?

[zirias]

Maybe my text for pkg-descr wasn't the best ... but first, I'm unsure about this patch as well, it's a separate review for a strong reason here ;)

The point is, without a patch, it's currently impossible to use dotnet at all when using DEFAULT_VERSIONS=ssl=libressl. Getting proper LibreSSL support upstream might be possible (I have no experience with the Microsoft guys' mindset about such things yet), but certainly a lot of work that will take some time.

I'll try to describe the exact limitations of the patch I added:

• It just disables quite a few things, which is commonplace with such patches and typically not problematic (like support for certain ciphers missing in LibreSSL), but one thing I had to disable was some callback for client certificate validation, because LibreSSL just doesn't offer the hook (it offers an older, somewhat problematic one in an entirely different place, so lots of changed code would be necessary for that). Therefore, I assume dotnet applications trying to use custom certificate validation would just fail to validate any cert. I don't expect any other breakage.
• Their implementation checks the OpenSSL version at runtime. I'm not even sure their approach could be used for proper LibreSSL support at all, what I did here is "hijack" one of the versions so LibreSSL is detected as a specific OpenSSL version. That's why dotnet code built with the patched dotnet *might* not run on machines using OpenSSL (if they use System.Security.Crypthography at all and if they are published in a form that bundles the native libs). But then, code built with OpenSSL1.x won't run on machines with OpenSSL3.x either, because as far as I understood their code, it can only compile the bits for up to the version available at build time ...

So in a nutshell, putting the patch behind an option and adding a warning was meant to tell anyone if you use dotnet for some serious ssl/crypto app (like self-hosted https services or whatever), don't use LibreSSL at that time.

With that explanation given, I'm totally fine with just keeping this patch locally, so I can use dotnet without completely switching to OpenSSL ;)