WIP: Experimental no-TLS version #77
Conversation
f02eadb to
bb1a94f
Compare
Does that mean it's still linking against libcurl even when HTTPS is off? What about zlib? Seems like if we want to avoid any native dependencies, we'd want to not use that was well, right? |
| @@ -41,6 +25,6 @@ before_install: | |||
|
|
|||
| install: true | |||
|
|
|||
| script: if [[ $RID == "osx" ]]; then ./build.libgit2.sh ; else ./dockerbuild.sh ; fi | |||
| script: ./build.libgit2.sh | |||
There was a problem hiding this comment.
I assume this is a temporary change? I would think we'd want to keep building things in docker to be able to better control things?
Also, we'll likely need to keep the alpine build (with tweaks to the RID) because of needing musl libc binary as well.
e4cffbb to
d03ea98
Compare
That's right. I was working on a PoC and turning off TLS was the important bits, so that I made sure that I didn't have any false positives.
No idea. This is just a spike, and if we decide to move it forward, even as a preview option, then I think that we are going to need to incorporate this into the main build. That means that there are a lot of build integration questions that need to get answered.
That would be disappointing. We shouldn't need a separate binary for alternative libc's. Do you know what problems we were having with interoperability? |
I was under the impression, perhaps mistakenly, that this would be a requirement. Would a binary compiled on Ubuntu work on Alpine? Using the binaries in the 235 release, I can see some differences in the
|
|
In comparison, the linux binary built from this PR looks much leaner already:
|
|
@bording @ethomson Do you guys have ETA for finishing this work (and libgit2/libgit2sharp#1618)? BTW, there is also dotnet/sourcelink#197 |
|
@tmat Regarding the RHEL6 problem, it's hard to test against RHEL since I don't have access to it. The current RHEL binary is actually built with CentOS 7. Apparently the glibc version on RHEL6 is too old. I guess as part of this work we need to ensure that the version of glibc we compile against is compatible with all of the distros on https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1-supported-os.md |
2d61e2f to
976c180
Compare
Nope! Please remember that this is a hobby project, it's done by people in their spare time, which none of us really have enough of anyway. If you're using this at your employer, in production code then you could help contributing! |
Build a version without HTTPS support to support built-in HTTPS.
a4e0231 to
6bde9d8
Compare
Update to 0.27.7 with callback fixes cherry-picked.
6bde9d8 to
6092bcd
Compare
|
Also, @tmat, if you don't need any networking in your application then you can use this today. All that's left here is to add networking back in, which is seeming sort of painful given some of the changes between .NET Core and .NET Framework. |
|
@ethomson I'd love to help and contribute, as I did before, but unfortunately I lack expertise in this area. I definitely understand this is not your full time job and didn't mean to push. Just wanted to know some kind of estimate to adjust our plans accordingly.
This is great to hear as we do not need networking at all. So, you're saying that the latest released build of LibGit2Sharp doesn't have dependencies that are only available on some Linux distros unless networking API is used? If so then that would resolve all our issues and we could indeed use it. |
I would like to add a caveat that I'm still not sure the single linux binary being built here is actually going to just work on all distros yet. |
No worries. This is my top priority for libgit2/LibGit2Sharp, but it's hard to have an ETA.
No, but I can create a prerelease of a new nuget package. I'm hesitant to release a new "LibGit2Sharp" package that drastically changes the way networking works in ways that aren't well tested. So I think that I'll create a new package entirely. I was thinking "LibGit2Sharp.Lite" since it's unencumbered by additional native binaries. (But - like 4.4BSD Lite - it sort of sounds like it's got reduced functionality, even though it doesn't. 🤔)
My goal is to only take a dependency on libc, so I expect it would work anywhere with ELF support. 😀 |
I'm still not sure that's true. For example, consider dotnet/sourcelink#197 and the change I made in #79 to attempt to fix it. The library clearly had metadata that specified "GLIBC" and a minimum version. That implies to me two things:
That's why I still want to do some more investigation and testing. |
I'm not really sure that's a good idea either, since it would be a temporary thing, right? If the changes here are made, we would only be supporting the "Lite" version, so which of the two LibGit2Sharp packages survives? |
I think that there are going to be tradeoffs with both, so I don't think it's crazy to think that we could support both in perpetuity. |
Hmm, given all the headaches around the native dependencies, I really wasn't considering keeping them around as a viable option. |
There's no doubt that this is going to be slower, what's unknown is by how much. And there's no win here on Windows: libgit2 on Windows uses the same libraries that .NET does, so this just adds several layers of indirection to get there. I think that this is the Right Thing for people who don't do any networking, or only a limited amount of networking. It's very possible that it's only the right thing in those circumstances and that everybody else will want to use the existing setup with .NET telling the native code to go do a lot of work and come back when it's done instead of marshalling every byte back and forth. |
|
@ethomson I get the motivation from the performance perspective, I'm just not sure keeping the linux dependencies around is a viable option that actually works for anyone. The problem with continuing to provide linux binaries as they currently are is that if you aren't just using LibGit2Sharp from something like a console or web app, then it's up to the consumer to understand all of the complicated RID loading logic to get the "right" library, and I'm not sure there's much we can do to fix that. For example, anyone currently trying to use LibGit2Sharp from an MSBuild task is going to be hating life as soon as they want to support .NET Core. It's also incredibly hard for someone to even figure out what the problem is when it doesn't work. It just seems like LibGit2Sharp (or more likely the thing they are trying to use that uses LibGit2Sharp behind the scenes) is broken and they have no idea why. The current RID selection was made based on my trying to optimize for the most coverage with the minimum amount of binaries, but me not being able to get access to every single distro and version of a distro means I've had to make some assumptions that have not always turned out to be true. To really cover things 100%, we'd need to have a separate binary for every single version of every single distro, and that's just not going to be acceptable to anyone. We also run into problems where the runtime.json that controls the RIDs .NET Core knows about isn't as updated as we need it to be to be able to target things the way we might need to, so that's another source of problems. And that doesn't even begin to consider mono support where we don't even have a way to automatically choose the correct linux binary. I wonder if we could so some sort of hybrid thing where Windows and maybe macOS continue to still be built with the native support and only turn it off for the linux builds where the native dependencies are nothing but a pit of hurting and pain? |
Indeed, that's a possibility. |
|
I am totally behind the idea of requiring the user to supply the native binaries. Right now I'm trying to build libgit2sharp with SSH support and run it on .NET Core and the process is... not fun. I figure it would be considerably easier if libgit2sharp just provided the wrappers over libgit2 then its up to the library's user to provide the binaries built with whatever settings are appropriate for their use case and target platforms. |
|
@alex-weaver this PR does not do that, but you can do that today. The https://github.com/libgit2/libgit2sharp.nativebinaries repo should have instructions for building and packaging your own. |
|
@ethomson thanks, I'll try that. Kinda OT for this thread, but is there any intent to merge this libgit2/libgit2sharp#1072 so that users can use ssh functionality by replacing the binaries without needing to modify libgit2sharp itself? |
|
@alex-weaver Not as-is. Making SSH support easier is a thing that we should pursue, but I don't want to be the one who's on the hook for dealing with security releases in SSH libraries. 😰 Discovery and dynamic loading seems reasonable; perhaps using a managed ssh library. |
|
Replaced by #96 |
Build a version without HTTPS support to support built-in HTTPS.
Starting this so that I can get a package built by the CI systems.