Bug 1549574 - standalone apps use system libcurl when running in scl
standalone apps use system libcurl when running in scl
Status: CLOSED ERRATA
Product: dotNET
Classification: Red Hat
Component: rh-dotnet20 (Show other bugs)
2.0
Unspecified Unspecified
unspecified Severity unspecified
: ga
: 2.0
Assigned To: Omair Majid
Radka Janek
Les Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-02-27 07:43 EST by Tom Deseyn
Modified: 2018-07-11 03:02 EDT (History)
7 users (show)

See Also:
Fixed In Version: rh-dotnet20-curl-7.47.1-1.4.el7 rh-dotnet20-dotnet-2.0.7-3.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-07-11 03:02:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:2167 None None None 2018-07-11 03:02 EDT

  None (edit)
Description Tom Deseyn 2018-02-27 07:43:00 EST
Description of problem:

Standalone apps HttpClient throws due to using system libcurl instead of scl libcurl.

How reproducible:

$ scl enable rh-dotnet20 -- bash
$ dotnet new console -o console
$ cd console
$ cat >Program.cs <<EOF
using System;
using System.Net.Http;

namespace console
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                HttpClientHandler clientHandler = new HttpClientHandler()
                {
                    ServerCertificateCustomValidationCallback = (sender, cert, chain, sslPolicyErrors) => { return true; }
                };
                using (var client = new HttpClient(clientHandler))
                {
                    var response = client.GetAsync("https://www.redhat.com").Result;
                    System.Console.WriteLine(response.StatusCode);
                }
            }
            catch (Exception e)
            {
                System.Console.WriteLine("Exception:");
                System.Console.WriteLine($"\t{e.Message}");
            }
        }
    }
}
EOF
$ dotnet run
OK
$ dotnet publish -r linux-x64
$ ./bin/Debug/netcoreapp2.0/linux-x64/publish/console 
Exception:
	One or more errors occurred. (The handler does not support custom handling of certificates with this combination of libcurl (7.29.0) and its SSL backend ("NSS/3.28.3").)
$ ldd ./bin/Debug/netcoreapp2.0/linux-x64/publish/System.Net.Http.Native.so
	linux-vdso.so.1 =>  (0x00007ffc515f0000)
	libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f50dca34000)
...

Actual results:

Standalone app uses system libcurl.

Expected results:

Standalone app uses scl libcurl.

Additional info:

- In our documentation, we recommend doing framework-dependent deployment (i.e. not standalone). Still, users can opt to use standalone.

- '/opt/rh/rh-dotnet20/root/usr/lib64' contains a 'libcurl.so'. self-contained is looking for 'libcurl.so.4'. Adding a symlink (e.g. ln -s libcurl-httpd24.so.4.4.0 libcurl.so.4) makes standalone pick up scl libcurl.
Comment 1 Omair Majid 2018-03-06 18:12:31 EST
Comparing that System.Net.Http.Native.so with the one we distrbiute:

$ ldd /opt/rh/rh-dotnet20/root/usr/lib64/dotnet/shared/Microsoft.NETCore.App/2.0.5/System.Net.Http.Native.so 
        linux-vdso.so.1 =>  (0x00007fff10510000)
        libcurl-httpd24.so.4 => /opt/rh/rh-dotnet20/root/usr/lib64/libcurl-httpd24.so.4 (0x00007f770ca22000)

Am I understanding it correctly that when publishing using -r linux-x64, the build pulls in System.Net.Http.Native.so from a nuget package. And that build of System.Net.Http.Native.so is linked against libcurl.so.4 instead of libcurl-httpd24.so.4?
Comment 2 Tom Deseyn 2018-03-07 03:50:08 EST
Omajid, indeed. The 'standalone' version of System.Net.Http.Native.so, that gets pulled from nuget.org, is linked against 'libcurl.so.4'.

This is also the case for the runtime and sdk packages built by Microsoft.
Comment 8 errata-xmlrpc 2018-07-11 03:02:45 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2167

Note You need to log in before you can comment on or make changes to this bug.