Images with Perl 5.8..5.24 are built with old version of git

[atoomic]

The docker images from 5.24 to 5.8 (and probably older) are providing a git version not supported anymore by GitHub
We should consider rebuilding all these images with an updated distro.

When trying to use these images to smoke Perl distro for example p5-TOML-XS here, we can see that the actions/checkout@v2 fallback to using the GitHub REST API instead of using git binary directly....

We can assume that git < 2.18 has some CVEs that we do not want to use...
To create a local Git repository instead, add Git 2.18 or higher to the PATH

actions/checkout output

Run actions/checkout@v2
/usr/bin/docker exec  18b7c324aeb62970e6c428445947204a2c2b0def760b624299cbca1e11e2dae8 sh -c "cat /etc/*release | grep ^ID"
Syncing repository: FGasper/p5-TOML-XS
Getting Git version info
Deleting the contents of '/__w/p5-TOML-XS/p5-TOML-XS'
The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH
Downloading the archive
Writing archive to disk
Extracting the archive
/bin/tar xz -C /__w/p5-TOML-XS/p5-TOML-XS/2c9a3eb2-f909-4461-b74d-60632e3ee131 -f /__w/p5-TOML-XS/p5-TOML-XS/2c9a3eb2-f909-4461-b74d-60632e3ee131.tar.gz
Resolved version FGasper-p5-TOML-XS-6d72200

copy: @FGasper / @oalders

discussed here Perl/docker-perl-tester#18

[oalders]

Would be nice to address the issue at this level.

[yosifkit]

For the images on Docker Hub (https://hub.docker.com/_/perl), only the tags listed in the official-images library/perl file are built/rebuilt: docker-library/official-images library/perl. See also https://github.com/docker-library/faq/#an-images-source-changed-in-git-now-what.

(I would guess that older versions fall under "unsupported" as per policy: https://perldoc.perl.org/perlpolicy#MAINTENANCE-AND-SUPPORT) From the view of official-images, we will build whatever Perl "supports" and puts in the library file (assuming its FROM is also still supported).

---

FYI, the perl:5.8 image was last built ~5 years ago:

$ docker pull perl:5.8
5.8: Pulling from library/perl
Image docker.io/library/perl:5.8 uses outdated schema1 manifest format. Please upgrade to a schema2 image for better future compatibility. More information at https://docs.docker.com/registry/spec/deprecated-schema-v1/
e5ad7970bc69: Pull complete 
a3ed95caeb02: Pull complete 
d54f4f30cd6f: Pull complete 
bbe5878d8681: Pull complete 
1df3bb332f6a: Pull complete 
3bba0561f23e: Pull complete 
b414ce41cb09: Pull complete 
4fd3658c936c: Pull complete 
662129b914c0: Pull complete 
Digest: sha256:52e63f8c1919222872e82c24737f9f546b640eb166021c8ecd0ebd71420ceb64
Status: Downloaded newer image for perl:5.8
docker.io/library/perl:5.8
$ docker images perl
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
perl         5.8       481e5a47c367   5 years ago   715MB

[zakame]

Thanks @atoomic @oalders for reporting, and @yosifkit for the follow-up!

I suppose the best we can do for all these older/unsupported perls would be to document these needing their git updated - also for the CI use-case, it might be better to use a separate container that does git operations separate from perl-specific ones (and as such this is already the case in GitHub Actions.) Would that work for you?

See also #88 - we'll likely get an even newer git version from the Debian 11 base when 5.34 drops.

[oalders]

Thanks @zakame! Based on the support policy, I think documenting that would be helpful. On our end, if we need a newer Git, we can figure it out. :)

[atoomic]

Correct me if I do not understand it right, you want to document it on your side, and on our side we take care of updating git for these legacy images we are using as base for our CI ones?
That works for me

[tianon]

Another option would be a one-time rebuild of these older versions (add them to library/perl, wait for all the builds, then remove them again).

I'm curious though, what's the use case for testing against unsupported/EOL versions of Perl?

[atoomic]

A typical use case is to publish a distribution to CPAN... and using GitHub workflow to check if regressions are introduced

[tianon]

I guess what I'm trying to ask is where does the demand for EOL Perl versions come from? Are there specific reasons why users might end up asking for / using EOL versions of Perl and thus need you to test against them?

For example, if some non-trivial number of users are running Ubuntu 16.04 with Perl 5.22, then it probably makes sense to run the tests in that environment directly with the version of Perl they're using instead of a stock upstream Perl 5.22, for which a Dockerfile that does FROM ubuntu \n RUN apt-get update && apt-get install -y perl might be sufficient and test what the real end-goal is. 😅

[oalders]

The Perl ecosystem has, for better or worse, an obsession with backwards compatibility. So, many authors of CPAN modules will support minimum Perl versions which are quite old. I work on some stuff that gets tested back to 5.8, which will turn 20 next year. Chances are you can work on a very old Perl and still run some fairly recent code. With many authors there's a feeling that they'll support the older Perls if there's not too much standing on your head involved, so it's not uncommon to want specifically to test a 5.8, 5.10 etc just to ensure you're not introducing new failures for users who may or may not actually exist.

[tianon]

Ahh, makes sense; thank you for the additional detail. 😄 ❤️

So in that light, I think doing a one-time back-fill rebuild is probably a good, safe option, especially since all the necessary Dockerfiles are already conveniently maintained here. 😄

[atoomic]

This would be awesome!
Thanks in advance
Please ping this case once the images are available

[tianon]

Ah, looking into this deeper, I think one sticking point is going to be that many of those older images are on Debian Jessie -- we'll need to bump those to at least Debian Stretch (which is the underlying source of the issue here anyhow).

Pinging the image maintainers, @PeterMartini @zakame -- what are your thoughts here? Do you think it's going to be a big lift getting these to compile successfully on a slightly newer Debian release, or is Devel::PatchPerl generally pretty reliable in that regard? 😅
(I guess maybe @atoomic is a better person to ask about this, given the relation to Devel::PPPort? 😄)

Edit: easier way to answer my own question was to try it out: #101 🤓

[atoomic]

@tianon I see no reasons why we would not be able to rebuild Perl 5.8 and later on a more recent distribution.
Trying to build older versions might be more tricky but this is also doable.