Re: [PATCH v2 0/5] drop support for ancient curl

On Wed, Jul 21 2021, brian m. carlson wrote:

[[PGP Signed Part:Undecided]]
On 2021-07-21 at 22:22:11, Ævar Arnfjörð Bjarmason wrote:

quoted

This series simplifies the http code by dropping support for curl
versions older than 7.19.4, released in March 2009.

This was last discussed on-list in 2017:
http://lore.kernel.org/git/20170809120024.7phdjzjv54uv5dpz@sigill.intra.peff.net (local)

My reading of why it didn't get integrated at the time was:

 - The original commit messages are opinionated about git not working
   on these versions anyway, as noted in the original thread that's
   only true of vanilla curl, but anyone impacted by these issues at
   the time was probably using e.g. RHEL, which had backports that
   confused the issue.

 - While in 2017 these versions were already ancient, RHEL 5 (released
   in 2007) was still seeing some notable production use.

   It finally got "we really mean it now" EOL'd in late 2020 when
   extended life-cycle support ended (see
   https://access.redhat.com/support/policy/updates/errata). RHEL 6
   does not have a libcurl affected by these changes.

 - It ended with a patch to "error on too-old curl", i.e. to make
   compiling on versions older than 7.19.4 an error. I've ejected that
   per the discussion about backports confusing that issue.

I'm in favor of this series.  I'm actually in favor of dropping support
for RHEL 6 as well, since there is nobody providing public security
support for it, and therefore nobody but people paying Red Hat (that is,
not this project) can be expected to safely run it.  I also think ten
years is about the reasonable maximum lifetime of software.

So, with or without those changes, this seems like a good approach to
me.

I'll clarify this along with other fixes in a re-roll, but I think our
policy shouldn't have anything to do with upstream promises of support,
but merely the trade-off of how easy it is for us to support old
software & how likely it is that people use it in practice along with
git.

So as an example we still say we support Perl 5.8, which is ridiculously
ancient as far as any notion of upstream security support goes (and as
an aside, does have real DoS issues exposed by e.g. the gitweb we ship).

But while we could probably bump that to something more modern nowadays
in practice we're not a mostly-Perl project, so I haven't found it to be
worth it to bump it when working on the relevant code.

I'm only using RHEL 5 as a shorthand for a system that's usually the
most ancient thing people want to build new gits with in practice.

It's just not the case that you can't run RHEL 5 or even RHEL 4 "safely"
even today. Upstream has just abandoned it, but that doesn't mean users
in the wild have. There's also CentOS, not everyone cares about IBM
corporate support policies.

E.g. in practice at a past-job I've had to build git using system
libcurl in a mixed environment which (and I forget the details) included
mostly today's equivalent of RHEL 8 and 7, but there was some system
using RHEL 5 in a closet somewhere still using puppet automation.

Why? Because (and I forget the details, but this example will do)
because it needed to operate some proprietary dongle requiring a RHEL 5
kernel driver that its vendor had since abandoned.

There were plans to move away from it, but that was maybe 1-2 years away
at the time. Meanwhile I had to build a git across the fleet, and it
would be a hassle to need to ship my own libcurl just because this
project wanted to have paternalistic version dependency policies.

I mean, if it's a matter of supporting that version being painful then
fair enough. I had some comments in the 2017 thread (or something linked
from it) about needing to package your dependencies not being *that* big
a deal.

Hence this series, I think on balance the improvement in maintainability
of the http code makes it worth it.

But let's not justify it with a user not being able to run such software
securely, in my example those ancient boxes were externally firewalled,
and in any case any practical security issues were probably with some
vendor's admin interface on them, not whatever ancient kernel they had.

On the other hand there's surely people who are running RHEL 5 today who
are running insecure setup, but let's not make it our job to force them
to move by virtue of being overly annoying about dependency version
requirements.

We should have the view that git's critical infrastructure and we should
be wary of breaking things. It would also just be counter-productive,
the result would probably be that the ancient box wouldn't get an
upgraded git, and would still have preventable CVE's in git itself
present (e.g. the gitmodules RCE).