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

[Jeff King <peff@peff.net>]

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

> 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