python 2 EOL (was: [PATCH v2 0/3] Fix broken CI on newer github-actions runner image)

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Nov 24 2022, Johannes Schindelin wrote:

> On Thu, 24 Nov 2022, Johannes Schindelin wrote:
> [...]
> The changes look good!
>
> One alternative I considered about 8e432f13bef8 (ci: install python on
> ubuntu, 2022-11-24) was to drop testing Python v2.x (it's years past end
> of life after all, see https://endoflife.date/python).

Just 2 years? :)

We're still pinning "perl" to a supported 5.8, which is so out-of-life
that I couldn't find a good reference to when exactly it went EOL. My
guess based on [1] and "perldoc perlhist" is sometime around 2009-2010.

> So I agree that the best idea in this patch series is the stop-gap
> solution to install `python2` on `ubuntu-22.04`, and deal with deprecating
> Python v2.x support separately, later, or never, whichever comes first ;-)

Yes, let's address that later. We had a recent discussion relating to
EOL-ing it in-tree. See the ML discussion around[2].

I would like to note that you seem to be assuming that upstream's EOL
for something like this should match our EOL for supporting the
software.

I think one could argue that, but that's not at all the stance we've
taken in the past, as the "perl" example shows.

I've personally wanted to bump the "perl" dependency more aggressively
for purely selfish reasons in the past (being able to use some newer
feature), but the reality is that people "back-port" newer git versions
onto various older platforms.

But in terms of the cost-benefit of the disruption that would incur I
also don't think it's worth it (although a bit past 5.8 is probably
justifiable at this point).

Someone using "perl" on an older system for git's tests and git-svn
etc. really doesn't need to worry much about the full security surface
that "perl" might provide, which includes e.g. all the CPAN libraries it
ships with, I expect that the same would go for "python".

The one potential security issue I can think of that we've ever had
because of it is that you could trick "gitweb" and the like into
ever-growing memory use if you had a perl version older than the "hash
randomization" security/DoS fix.

But other than that we're not exposing perl, python etc. directly over
the Internet, so I think we don't need to be too paranoid about it.

1. https://endoflife.date/perl
2. f7b5ff607fa (git-p4: improve encoding handling to support
   inconsistent encodings, 2022-04-30)