Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
/ corefx Public archive

[release/2.1] Add hybrid support for OpenSSL 1.0 and 1.1 #34443

Merged
merged 7 commits into from
Feb 13, 2019

Conversation

omajid
Copy link
Member

@omajid omajid commented Jan 8, 2019

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.

@bartonjs
Copy link
Member

bartonjs commented Jan 8, 2019

@omajid Why 2.2? If it's put into 2.1 it'll auto-merge to 2.2.

@omajid
Copy link
Member Author

omajid commented Jan 9, 2019

@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.
@omajid omajid changed the base branch from release/2.2 to release/2.1 January 10, 2019 01:33
return 1;
}

#ifndef SSLEAY_VERSION
Copy link
Member Author

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
Copy link
Member Author

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();
Copy link
Member Author

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.

@bartonjs bartonjs changed the title [WIP] [release/2.2] Add hybrid support for OpenSSL 1.0 and 1.1 [WIP] [release/2.1] Add hybrid support for OpenSSL 1.0 and 1.1 Jan 10, 2019
@omajid
Copy link
Member Author

omajid commented Jan 10, 2019

The System.Security.Cryptography.X509Certificates.Tests failure (before my last change) looks like #30889

@bartonjs
Copy link
Member

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.

Copy link
Member

@bartonjs bartonjs left a 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.

@omajid
Copy link
Member Author

omajid commented Jan 17, 2019

@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.

@bartonjs
Copy link
Member

@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 😄.

* Drop pal_asn1_print in favor of the managed code that is already used on macOS.

* Add handling of T61 strings to ManagedCertificateFinder.DerStringToManagedString.
@omajid
Copy link
Member Author

omajid commented Jan 17, 2019

@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.

@omajid
Copy link
Member Author

omajid commented Jan 19, 2019

@bartonjs should we look into backporting #33468 (as a separate PR) too?

@bartonjs
Copy link
Member

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).

@omajid
Copy link
Member Author

omajid commented Jan 21, 2019

Okay. Lets ignore #33468 for now, then.

@bartonjs
Copy link
Member

Description

Backport 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 Impact

As 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

Risk

Low, this is a backport of a change that has been in 3.0 since August 2018.

@leecow
Copy link
Member

leecow commented Jan 31, 2019

@danmosemsft to shepherd through shiproom

@danmoseley danmoseley added the Servicing-consider Issue for next servicing release review label Feb 1, 2019
@danmoseley danmoseley added this to the 2.1.x milestone Feb 1, 2019
@jamshedd jamshedd modified the milestones: 2.1.x, 2.1.9 Feb 7, 2019
@jamshedd jamshedd added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Feb 7, 2019
@jamshedd
Copy link
Member

jamshedd commented Feb 7, 2019

Approved for 2.1.9.

@omajid
Copy link
Member Author

omajid commented Feb 13, 2019

@bartonjs Do you know what the schedule for merging this looks like? Are we waiting for some repo to open up for commits?

@bartonjs
Copy link
Member

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?)

@wtgodbe wtgodbe merged commit 16a6d0b into dotnet:release/2.1 Feb 13, 2019
omajid added a commit to omajid/dotnet-corefx that referenced this pull request Mar 6, 2019
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
      ^
bartonjs pushed a commit that referenced this pull request Mar 7, 2019
* 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants