Nerdbank.gitversioning: Builds broken on Ubuntu 19.04

[bradwilson]

The dependency on LibGit2Sharp brings in a binary dependency on an old and insecure version of libssl on Linux which is no available (because of the security vulnerabilities).

/home/brwilso/.nuget/packages/nerdbank.gitversioning/3.0.26/build/Nerdbank.GitVersioning.targets(63,5): error MSB4018: ---> System.DllNotFoundException: Unable to load shared library '/home/brwilso/.nuget/packages/nerdbank.gitversioning/3.0.26/build/MSBuildCore/../runtimes/linux-x64/native/libgit2-572e4d8.so' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libssl.so.1.0.0: cannot open shared object file: No such file or directory [/home/brwilso/dev/xunit/xunit/src/xunit.v3.assert/xunit.v3.assert.csproj]

[AArnott]

Great. I've added Ubuntu Disco to the test targets with 3a9dc12e4783cb5a9cdef24db9eb89e617d82e1d and repro'd the problem.

[AArnott]

@ethomson do you supposed updating libgit2sharp from 0.27.0-preview-0007 to 0.27.0-preview-0024 will fix this?

[AArnott]

It looks like the libgit2sharp update (#393) did not fix this. Looking at the runtimes folders in libgit2sharp.nativebinaries, there are dedicated folders for ubuntu 16 and 18, but not (yet) 19.

[ethomson]

Sorry, I don't know. @bording might know.

[ethomson]

Also, one of the things that we experimented with when I was still active in LibGit2Sharp was creating a build of libgit2 that removed the OpenSSL dependency entirely. I think that long-term, using the .NET HTTP stack probably makes sense, which would eliminate all the stupid OpenSSL linkage.

However, in a project like this that doesn't need network access (I think?), then you could simplify with a build of LibGit2Sharp that didn't have any HTTPS linked in.

If this is something that you're interested in then I think that it would be worth understanding the publishing mechanism since things are a bit of a mess on nuget.org right now and ideally will be cleaned up.

[AArnott]

Thanks for the quick response. I'll try to figure out how much time it would take to put a solution together given the two of you aren't so active on this at present.

[bording]

With all the new distros that have come out recently that .NET Core 3.0 has support for, there's a need to go back through and figure out what additional native binaries need to be added to the package to get them all working.

That's something I need to take some time and do (and it does take some time getting it all sorted out), but as @ethomson has mentioned elsewhere, my free time to devote to LibGit2Sharp has been sparse lately.

I know I won't have time this weekend, but I'll see what I can do about it next week.

[AArnott]

Thanks, @bording. Would that time be better spent completing https://github.com/libgit2/libgit2sharp/pull/1618 to switch libgit2sharp over to the managed HTTPS stack so that this is no longer an issue? I don't know how close that PR is to finishing.

[bording]

Ideally, yes that PR would get finished up, and then we'd have a much simpler native binaries package. However, I really would need @ethomson's assistance to make that happen. When I took a look at the test failures on that branch, from what I could tell, they were related to things on the native/libgit2 side of things, and that's something I don't have enough knowledge about to get it working on my own.

[ethomson]

I don't think that the problem is on the native side. (Looking at the build logs, I do see No error message was set by the native library, or whatever that message is precisely. That's the message that LibGit2Sharp sets when git_error_last returns NULL.)

What's actually happening is:

LibGit2Sharp calls libgit2
libgit2 calls back into LibGit2Sharp (the custom transport)

The custom transport is failing, but didn't set an error message with libgit2
libgit2 just reports the failure back to LibGit2Sharp
LibGit2Sharp queries libgit2 to get the error message, but LibGit2Sharp (the custom transport) itself didn't set that error message.

Anyway, sans proxy and default credentials, this did work when it was using ye olde HTTP APIs. When I hurriedly moved it over to HttpClientHandler, I broke something.

I'll see if I can find some time to kick this a little bit further down the road.

[NickMSW]

I'm also seeing this issue on my Alpine builds:
root/.nuget/packages/nerdbank.gitversioning/3.0.26/build/Nerdbank.GitVersioning.targets(63,5): error MSB4018: ---> System.DllNotFoundException: Unable to load shared library '/root/.nuget/packages/nerdbank.gitversioning/3.0.26/build/MSBuildCore/../runtimes/alpine-x64/native/libgit2-572e4d8.so' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libssl.so.1.0.0: No such file or directory (needed by /root/.nuget/packages/nerdbank.gitversioning/3.0.26/build/MSBuildCore/../runtimes/alpine-x64/native/libgit2-572e4d8.so)