OpenSSL 1.1 support in .NET Core 2.1

[omajid]

RHEL 8 does not include OpenSSL 1.0. It only includes OpenSSL 1.1. .NET Core 2.1 (the current LTS release) does not work on RHEL 8 because of this.

(.NET Core 3.0, which support both OpenSSL 1.0 and 1.1 should work just fine.)

[omajid]

I did a backport of the OpenSSL 1.1 to .NET Core 2.1 here: https://github.com/omajid/corefx/commits/openssl-1.1. It seems to work on RHEL 8, but I have not done extensive tests. This was based on dotnet/corefx#30807.

[stephentoub]

cc: @bartonjs

[bartonjs]

dotnet/corefx#32006 and dotnet/corefx#32483 are what we'd backport (though we'd have to decide if we want to leave 1.1.x as preferred, or move it to fallback... wouldn't matter for RHEL since as a distro you should be building direct instead of portable).

It's something we've discussed internally, but the feeling was "definitely not before even a preview of 3.0 is out". That event is, of course, now in the past.

[omajid]

Would it make sense to backport the OpenSSL 1.1 changes to both 2.2 and 2.1?

Also, would you prefer a focused backport? That is, we just essentially cherry-pick dotnet/corefx#32006 and dotnet/corefx#32483? Or would you prefer that we try and backport the additional changes that were made to master that dotnet/corefx#32006 depends on (aside from the C++ to C changes)? I think there's a few that dotnet/corefx#30807 links to.

[bartonjs]

The focused backport; just those two PRs cherry-picked (or, if it's across the C++ -> C transition, cherry-ported might be more appropriate).

If other things are required for structure reasons, then backporting those things seems better than inventing a new solution... but I guess that's a case-by-case thing. (I don't see much, aside from the C++ to C change)

[omajid]

I have found the following commits that are needed to make this port straight forward (almost mechanical). Let me know if any of them seem inappropriate for backporting:

• OpenSSL: Parse the version number from the SSLeay numerical value corefx#30870 (Honor converters for underlying types of Nullable<T> specified with JsonConverterAttribute #32006 touches the same code for the ssl version)
• NetFX compatibility fixes for X500DistinguishedName. corefx#30572 (needed for the next one)
• OpenSSL: Drop pal_asn1_print in favor of the managed code corefx#30868 (removes code that calls api that is not present in openssl 1.1)
• OpenSSL: Replace pkcs7_[new/content_new/set_type/add_certificate] with single pkcs7_sign call. corefx#30869 (this removes a bunch of shims that the hybridization later touches)

After the hybridization, we might want these:

• OpenSSL: Relax the error checking code to cater for different versions. corefx#30889 (fix handling of some openssl return codes)
• Use HMAC_CTX_free() instead of free() on a HMAC_CTX* corefx#34222 (typo fix)

[bartonjs]

• 30870 is dangerous, since it removes an export. Since the main benefit of it (aside from "numbers are better than strings") is "and BoringSSL also works", this should be avoided if possible.
• 30869 similarly is more about being friendlier with BoringSSL; and removes exports. This should be avoided if possible.
• 30889 is just about BoringSSL, and is just for a test, should not be backported.

In contrast:

• 34222 should be backported, yeah 😄.

Removing exports, and depending on new exports, has some complexity cases around the execution and deployment models, so they should really be avoided in servicing. Changing the managed code to no longer call exports is fine, but they should just hang around as unused code.

[MichaelSimons]

It appears this is also affecting Alpine3.9 as well which was recently released and supports libssl1.1. The 2.1 support matrix includes Alpine 3.7+.

No usable version of the libssl was found

[omajid]

@MichaelSimons dotnet/corefx#34443 should fix this. Is there any way you can try out that PR on alpine 3.9 to verify that it works?

[bluca]

This is also a problem on Debian 10, which likewise doesn't ship libssl 1.0 anymore, so vsts universal package downloads do not work as ArtifactTool uses System.Security.Cryptography.Native.OpenSsl.so.

Any ETA on when a new build of the 2.1.x core libraries will be available with this fix?

Thanks!

[omajid]

dotnet/corefx#34443 has the 2.1.9 label. So it should get included starting with that release. I don't know when that gets released. Looking at the release history, probably within a few months? I have had decent success building .NET Core from source (using https://github.com/dotnet/source-build/) with dotnet/corefx#34443 applied locally. This is what I am doing on RHEL 8 at the moment.

[bluca]

Thanks, yes I've managed to build it locally as well, and dropping the updated shared library in vsts' directory works.

[omajid]

@bartonjs, should we close this issue now?

[bartonjs]

@omajid Yep, good call 😄