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

From: Jeff King <peff@peff.net>
Date: Apr 4, 2017, 20:16 UTC
Message-ID: <20170404201601.jhjq2x5qgcneroo4@sigill.intra.peff.net>
In-Reply-To: <CACBZZX6W+fbCg7xXKuM=iqnSYFENBYxYT1WJmoOvYYCBEkX=hQ@mail.gmail.com>

On Tue, Apr 04, 2017 at 04:06:46PM +0200, Ævar Arnfjörð Bjarmason wrote:

Show 15 quoted lines

> > But a couple of #ifdef's? C'mon, man, we can carry this *without sweat*
> > indefinitely ;-)
> 
> I don't really care about applying this patch, but I wouldn't mind
> seeing it applied.
> 
> I just wanted to clarify the counteractive point that it's not unusual
> for some (particularly corporate) environments to be compiling fresh
> upstream releases of some software against really ancient versions of
> other upstream libraries.
> 
> But as Frank Gevaerts's reply (thanks!) which came after your reply
> points out, this code has already been broken since v2.12.0, so it's
> rarely used enough that nobody's reported being unable to compile git
> 2.12.0 on e.g. CentOS 5 >2 months since release.

Yeah, this is exactly the kind of thing I was wondering about (but was too lazy to actually build an ancient version of curl -- thank you, Frank).

In this case it was a compile error, which was obvious. I'm much more worried about subtle interactions, or the fact that some of the ifdefs are around security features that get ignored. In some cases we at least issue a warning, but not always. E.g., we silently ignore http.sslcapath. Depending what you're using it for that could fail closed (if you were trying to add a CA) or open (if you were trying to restrict to a specific CA).

-Peff