-
Notifications
You must be signed in to change notification settings - Fork 4.9k
[release/2.1] Add hybrid support for OpenSSL 1.0 and 1.1 #34443
Conversation
@omajid Why 2.2? If it's put into 2.1 it'll auto-merge to 2.2. |
Crud. I didn't realize that. I figured we would backport into 2.2 and then 2.1 if 2.2 works okay. Let me do this against 2.1, then. |
* Don't write a separator after the empty DN * Make T61String behave like it does on Windows (UTF-8 with a Latin-1 fallback) * Use the managed decoder on Linux, instead of a lot of P/Invokes back into OpenSSL.
3cf174a
to
757ab1f
Compare
return 1; | ||
} | ||
|
||
#ifndef SSLEAY_VERSION |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ifndef/endif
is new.
@@ -1242,6 +1271,26 @@ extern "C" int32_t CryptoNative_LookupFriendlyNameByOid(const char* oidValue, co | |||
return 0; | |||
} | |||
|
|||
#ifndef OPENSSL_VERSION |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This hunk is new. The code in master uses OpenSSL_version_num
instead.
#include "pal_compiler.h" | ||
#include "opensslshim.h" | ||
|
||
extern "C" char* CryptoNative_SSLEayVersion(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reduced the number of delcarations in this file to the bare minimum that's required to build.
src/Native/Unix/System.Security.Cryptography.Native/pal_ssl.cpp
Outdated
Show resolved
Hide resolved
The System.Security.Cryptography.X509Certificates.Tests failure (before my last change) looks like #30889 |
Ah, the part of that change that stopped looking at the string seems worth taking; but the part that changed how the error code was processed seems unrelated to this effort. |
src/Native/Unix/System.Security.Cryptography.Native/opensslshim.cpp
Outdated
Show resolved
Hide resolved
src/Native/Unix/System.Security.Cryptography.Native/pal_dsa.cpp
Outdated
Show resolved
Hide resolved
src/Native/Unix/System.Security.Cryptography.Native/pal_ssl.cpp
Outdated
Show resolved
Hide resolved
src/System.Security.Cryptography.OpenSsl/tests/EcDsaOpenSslTests.cs
Outdated
Show resolved
Hide resolved
600d472
to
0f60286
Compare
src/Common/src/Interop/Unix/System.Net.Http.Native/Interop.VersionInfo.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to reduce the temporary strings in the version number builder; otherwise this looks ready for the servicing process.
@bartonjs Do the CI failures look related to my changes? Or are they known issues? I am wondering what I need to do about that. |
@omajid My guess is that they're intermittent failures. If you're going to add a commit for the temporary strings problem I'd just wait for that automatic rerun, or we can just run them again. @karelz https://mc.dot.net/#/user/omajid/pr~2Fjenkins~2Fdotnet~2Fcorefx~2Frelease~2F2.1~2F/test~2Ffunctional~2Fcli~2F/0f602865e769f68a58d9921a17ae06b86c0a9972/workItem/System.Net.Security.Tests/analysis/xunit/System.Net.Security.Tests.ServerAsyncAuthenticateTest~2FServerAsyncAuthenticate_AllClientVsIndividualServerSupportedProtocols_Success(serverProtocol:%20Ssl3) looks an awful lot like https://github.com/dotnet/corefx/issues/24356; but I don't know a good way to find out if it has been recently failing in release/2.1. I'm fairly certain that changing how we bind to OpenSSL on Linux shouldn't cause these loopback adapter-based tests to fail on Windows, though 😄. |
0f60286
to
717cda2
Compare
* Drop pal_asn1_print in favor of the managed code that is already used on macOS. * Add handling of T61 strings to ManagedCertificateFinder.DerStringToManagedString.
@bartonjs I fixed the span issues (and pushed a rebase) but I found another issue building non-portable against openssl 1.1. Working on a fix for that now. |
717cda2
to
813afa3
Compare
src/Native/Unix/System.Security.Cryptography.Native/pal_asn1_print.cpp
Outdated
Show resolved
Hide resolved
Hmm, that PR is slightly harder. It should be a separate thing, since shiproom might feel differently about that particular part of the change (that it should be more nuanced, etc). |
Okay. Lets ignore #33468 for now, then. |
DescriptionBackport support for OpenSSL 1.1 to .NET Core 2.1. This enables 2.1 to continue running on newer Linux distros as they start to drop support for OpenSSL 1.0. Customer ImpactAs a differentiator from .NET Core 3.0, on 2.1 (and 2.2) the runtime will prefer OpenSSL 1.0. So existing customers on existing OSes will be unaffected. Customers who do not have OpenSSL 1.0, but do have OpenSSL 1.1 will cease getting an error that the dependency cannot be found and their scenarios will work. Regression?No, reaction to evolution of new OS versions Packaging reviewed?Affected components are all part of Microsoft.NETCore.App RiskLow, this is a backport of a change that has been in 3.0 since August 2018. |
@danmosemsft to shepherd through shiproom |
Approved for 2.1.9. |
@bartonjs Do you know what the schedule for merging this looks like? Are we waiting for some repo to open up for commits? |
The release branches have controlled merging, with lockouts during the time that a release is in progress. Since 2.1.8 and 2.2.2 released yesterday I'd expect the branches to open soon (today/tomorrow?) |
This was a mistake in e4bcbd5 (dotnet#34443) made when backporting it to the release branches. All other uses of NEED_OPENSSL_1_0 are guarded by an #ifdef, not an #if. This one should be too. The warning is seen when building corefx using source-build. I couldn't observe it directly: source-build/src/corefx/src/Native/Unix/System.Security.Cryptography.Native/pal_asn1_print.cpp:34:5: error: 'NEED_OPENSSL_1_0' is not defined, evaluates to 0 [-Werror,-Wundef] #if NEED_OPENSSL_1_0 ^
* Change #if NEED_OPENSSL_1_0 to #ifdef NEED_OPENSSL_1_0 This was a mistake in e4bcbd5 (#34443) made when backporting it to the release branches. All other uses of NEED_OPENSSL_1_0 are guarded by an #ifdef, not an #if. This one should be too. The warning is seen when building corefx using source-build. I couldn't observe it directly: source-build/src/corefx/src/Native/Unix/System.Security.Cryptography.Native/pal_asn1_print.cpp:34:5: error: 'NEED_OPENSSL_1_0' is not defined, evaluates to 0 [-Werror,-Wundef] #if NEED_OPENSSL_1_0 ^ * Disable used-but-marked-unused warnings in System.Security.Cryptography.Native When building in non-portable mode, some OpenSSL 1.1 function defnitions that are marked as unused can be picked up by our build. When those functions are called, clang reports a warning and fails the build: src/Native/Unix/System.Security.Cryptography.Native/openssl.cpp:432:12: error: 'sk_ASN1_OBJECT_num' was marked unused but was used [-Werror,-Wused-but-marked-unused] return sk_ASN1_OBJECT_num(eku); ^ This 'unused' attribute was recently added to sk_* methods in OpenSSL 1.1: openssl/openssl#8246
See https://github.com/dotnet/corefx/issues/33870 for the background.
This includes ports of:
And a new commit (60e4274) that makes portable builds of .NET Core 2.1 prefer OpenSSL 1.0.x over 1.1.x. This is to try and avoid any surprises if both OpenSSL 1.0 and 1.1 are installed on a system and the user upgrades from a previous 2.1 release to one with this update.