On Thu, Jul 28, 2016 at 06:36:58PM -0400, Peter Colberg wrote: > On Thu, Jul 28, 2016 at 03:26:46PM -0700, Josh Triplett wrote: > > Unfortunately, libgit2 also doesn't seem to support any TLS library > > other than OpenSSL. That's a serious problem for GPLed software, and > > Debian already has some GPLed software linking to libgit2 (which led to > > the switch to link against the gnutls version of libcurl). > > I am suggesting to provide two variants of libgit2, without and with > support for https://, with the latter linking to OpenSSL, similar to > the multiple variants of libcurl. > > https://bugs.debian.org/832798
That would be a maintenance pain, and it would still mean that GPLed applications couldn't use libgit2 with https URLs. (It might work as a temporary solution, but it doesn't seem like the right long-term solution.) I talked with libgit2 upstream about what it would take to support https without OpenSSL. They suggested that they weren't interested in using libcurl for HTTPS, even if it were fixed to support what they need (retrieving the original x509 certificate chain unparsed for a verification hook) and that fix became widely available. libgit2 doesn't use much of libcurl, since libgit2 only supports switching to the "smart" HTTP transport. Instead, libgit2 upstream would prefer to see a new TLS transport, selectable at compile time. They'd be willing to add support for that. Would someone experienced with either GnuTLS or NSS be up for writing a new TLS transport for libgit2? (I've CCed the maintainers of each.) - Josh Triplett
