Add Alpine 3.18 variant

[jnoordsij]

Description

Adds latest Alpine version (3.18) and removes oldest one (3.16).
See also #1813.

Motivation and Context

Provide latest Alpine version (see https://alpinelinux.org/posts/Alpine-3.18.0-released.html).

Testing Details

Example Output(if appropriate)

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Others (non of above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[jnoordsij]

Note: builds seem to be failing; I'll check later if I can figure out why. If anyone else does see, make sure to let me know!

[nschonni]

There are some issues with Actions right now https://www.githubstatus.com/incidents/pr3498h3qkfy so maybe related to the failures

[jnoordsij]

Ok, I figured the issue is due to Alpine 3.18 shipping with gnupg 2.4 instead of 2.2 (or more precisely version 2.4.1), which uses a new keybox daemon by default, see gpg/gnupg@d9e7488.

So the options to fix this are:

1. Install gnupg-keyboxd as well in the Alpine Dockerfile; however this is not compatible with the Alpine 3.17 version, so that would require either dropping 3.17 as well or doing some advanced templating
2. The workaround I just commited, that creates an empty config file to prevent the auto-creation of the gnupg config file that enabled the new keybox daemon. This can then be replaced with option 1. once Alpine 3.17 support is dropped (probably in approx. 6 months when Alpine 3.19 is released).

Edit: builds seem to be passing now, the workflow failures that are still occurring all seem to be GitHub internal errors which are probably related to the issues with Actions that are going on right now.

[jnoordsij]

I think this is ready for review; can anyone let me know if any further work is required?

[SimenB]

I restarted CI at least

[SimenB]

I think this is fine to do - I don't think we have a set policy for alpine versions or what the tags point to?

[nschonni]

@tianon @yosifkit how are you handling this GPG change on the other official images?

I'm leaning towards the folder should get added and then removed, but I'm fine with changing the defaults since we've done that in the past

[tianon]

For most of the images we maintain, we handle this by setting a two-version cap on the number of distro versions we'll support concurrently (to keep the matrix sprawl / build/maintenance load under control), adding aliases for users to pick a specific version (xxx:yyy-alpine3.17, for example), and then allowing the bare alpine alias to move to "latest" (which isn't always ideal, but it keeps things consistent and still has an escape hatch for users who need to pin back to the older or need to stick to pinning the older).

[nschonni]

@tianon thanks, we'll keep to that 2 version cap, but the question was more about #1895 (comment)

[tianon]

Ah, sorry! We typically do GNUPGHOME="$(mktemp -d)"; export GNUPGHOME; ...; rm -rf "$GNUPGHOME" so the directory pre-exists and we thus don't hit this in most of our images. In this case, I'd probably suggest something similar (making sure the directory pre-exists so you get the fallback behavior for now, since keyboxd doesn't actually make anything better for the docker build use case AFAIK).

[jnoordsij]

I've updated the template to use a temporary GNUPGHOME directory, modelled after the PHP official image (see https://github.com/docker-library/php/blob/master/Dockerfile-linux.template#L211-L220).

[jnoordsij]

For consistency I opened #1901 as a follow-up to alter the Debian-based image builds in a similar way.

[nschonni]

LGTM, one minor suggestion, but not blocking

[nschonni]

Minor, but maybe this should move with the rest of the cleanups at line 69

[jnoordsij]

Yeah I wasn't sure about the best location and chose to follow the PHP-approach; this includes a manual gpgconf --kill all which I'm not sure is necessary (i.e. it works fine on my end without it, but maybe it has a more specific purpose) which can only be run when gpg is still installed. So in that case, I could only move it down to be just above the apk del call. If you prefer that, let me know and I'll update it!

[tianon]

On gpgconf --kill all specifically, removing the GNUPGHOME directory will often fail with race conditions around some of the socket files that end up in there, and we've found that explicitly requesting that GnuPG kill all background daemons first helps with those race conditions (it doesn't completely eliminate them, but it does significantly lessen them).

[jnoordsij]

@nschonni as mentioned, if we keep the gpgconf --kill all call, this can only be moved as far down as just above line 66. Do you still prefer this, or shall we keep it the current way?

Alternatively, we could just merge this for now, as it is functionally equivalent, move the discussion to #1901 and find a definitive approach there.

[uhthomas]

Is this PR ready to be merged? I'm looking to use a new package version in Alpine 3.18.

[aaleksandrov]

Hey, is it possible to get this one merged ? Apline 3.17 (and hence - all existing alpine-based node images ) has a security vulnerability in openssl 3.0.8-r3 https://hub.docker.com/layers/library/alpine/3.17/images/sha256-b6ca290b6b4cdcca5b3db3ffa338ee0285c11744b4a6abaa9627746ee3291d8d?context=explore

[nekopsykose]

has a security vulnerability in openssl 3.0.8-r3

that was fixed over a month ago in 3.0.8-r4 and all you have to do is apk upgrade

[alexkorsun]

Alpine 3.18 has the updates for the musl libc related to the DNS over TCP.
musl libc 1.2.4 – now with TCP fallback in DNS resolver
So it's useful for many projects to move to the image based on 3.18.

[bricss]

It would be great 🎉 to see it land 🛬

[uhthomas]

Sorry, I really don't mean to be impatient. Thank you for your hard work with this PR. Is there anything blocking this change? I'm really keen to see it through as it's blocking some stuff I'm working on.

@jnoordsij @tianon @nschonni @SimenB

[ttshivers]

This all looks good to me. I think we should merge this and resolve the gpg concerns with #1901

[JamieKeeling]

Sorry, I really don't mean to be impatient. Thank you for your hard work with this PR. Is there anything blocking this change? I'm really keen to see it through as it's blocking some stuff I'm working on.

@jnoordsij @tianon @nschonni @SimenB

Echoing this, is there an indication as to when this update will be merged and made available?

[github-actions]

Created PR on the official-images repo (docker-library/official-images#14779). See https://github.com/docker-library/faq#an-images-source-changed-in-git-now-what if you are wondering when it will be available on the Docker Hub.

[H01001000]

Hmm, I saw the alpine3.18 is online but all alpine3.18 images don't contain amd64 arch
And the default alpine image is still using 3.17

[Razican]

It seems it's happening with multiple official alpine3.18 images for multiple projects.

[jnoordsij]

By the looks of things, there was some kind of delay with the amd64 arch builder in the Jenkins infrastructure, but since approx. 15 hours ago the new Alpine 3.18-based images seem to be available for amd64 too.