Re: [RFC] dropping support for ancient versions of curl

From: Jeff King <peff@peff.net>
Date: Apr 10, 2017, 18:22 UTC
Message-ID: <20170410182215.figy7hm4sogwipyz@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.20.1704071257560.4268@virtualbox>

On Fri, Apr 07, 2017 at 01:18:30PM +0200, Johannes Schindelin wrote:

Show 7 quoted lines

> On Thu, 6 Apr 2017, Jeff King wrote:
> 
> > And it's not like people on ancient mission-critical systems get cut
> > off. They can still run the version of Git they were running when their
> > OS went out of support.
> 
> You keep baiting me, so I'll bite, after resisting the urge for so long.

I wasn't going to respond to this, because I didn't feel like the discussion was going anywhere. But I ran across yet another issue related to this today that hadn't been mentioned yet.

Your story shows that yes, it's convenient when old libraries are supported. I don't dispute that. But one of my earlier points is that this isn't just about maintenance burden (which I agree is not huge); it's about whether we do a disservice to users to pretend that Git is even remotely tested with older versions of curl.

For instance, did you know that versions of curl prior to v7.17 rely on any strings fed via curl_easy_setopt() remaining valid for the lifetime of the curl handle[1]?

We have some workarounds for this in old code (for example, see the handling of CURLOPT_PASSWORD in http.c), but a lot of calls have been added since then. I think there's a very good chance there are use-after-free bugs when Git is compiled against an older curl.

I'm concerned that we're giving users a false sense of what is reasonable to compile against. You can reframe that as a maintenance question (we _could_ find and fix those bugs), but that changes the cost/benefit analysis.

[1] http://public-inbox.org/git/alpine.DEB.2.00.1306180825460.24456@tvnag.unkk.fr/

-Peff