Re: [PATCH v2 0/5] drop support for ancient curl
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jul 22, 2021, 07:09 UTC
- Message-ID
- <87czravm96.fsf@evledraar.gmail.com>
- In-Reply-To
- <YPimBp+TkaJ9ycuM@camp.crustytoothpaste.net>
On Wed, Jul 21 2021, brian m. carlson wrote:
Show 36 quoted lines
> [[PGP Signed Part:Undecided]] > On 2021-07-21 at 22:22:11, Ævar Arnfjörð Bjarmason wrote: >> 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 >> >> 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).