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

On Thu, Nov 24 2022, Johannes Schindelin wrote:

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.

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)