Stable images are still based on alpine 3.17

[orgads]

Describe the bug

Looks like the base image was updated long ago in 7c10a4a, but the official images are still based on 3.17.

To reproduce

https://hub.docker.com/_/nginx/tags?page=1&name=1.24.0-alpine

Expected behavior

It should be based on alpine 3.18.

[thresheek]

We did not have a stable release for 1.24.x, and moving the same tag between different OS versions has been proven a bad idea.

We'll wait until there is 1.24.1 release to bump this.

[orgads]

Is 1.24.1 expected soon?

If not, can you maybe add images named alpine3.18, and leave the existing "alpine" named images based on 3.17?

[thresheek]

There is no ETA for 1.24.x version bump.

Having multiple per-OS versions supported would be an approach multiple official images take, indeed - I'm not sure it's super beneficial for nginx though, as we don't really use a lot of fancy new features of the OS itself. And there is still some overhead in shipping the images.

What would be your usecase for stable and 3.18, where you can't use mainline? (see https://www.nginx.com/blog/nginx-1-18-1-19-released/#NGINX-Versioning-Explained for differences)

[orgads]

Alpine 3.17 is vulnerable to CVE-2022-48174.

[thresheek]

Alpine 3.17 is still supported for security fixes until 2024-11-22, so we can expect it to get the updated busybox. When this happens, and a new 3.17 minor release is available and published to Docker Library, nginx alpine-based image will be automatically rebuilt and the issue will be resolved.

Other option is to migrate to mainline nginx images based on alpine.

[Kinqdos]

What about Alpine 3.19? I use nginx as my base image for a php application. Php 8.3 comes with the alpine 3.19 repo. Is there any reason to not go with the latest os version?

[thresheek]

Hi @Kinqdos !

Moving the same tag (e.g. nginx:stable) without a new stable release to the new OS is likely to break the already existing setups.

Which is why we typically change the underlying OS when we have new nginx releases - this way users can choose to upgrade or roll back if their setups are broken.

Unfortunately there hasnt been a new release of 1.24 (stable) series, so there's that.

[Kinqdos]

Thank you for your answer @thresheek, but isn‘t it possible to release the explicit tag (eg: 1.25.4-alpine3.19) while keeping the „base“ tag? Or would this lead to, too much confusion?

[thresheek]

Yeah, I think it will be beneficial if we provide multiple alpine-based tags simultaneously, e.g. for the last two releases. We had similar requests before.

We probably want to extend that to multiple debian versions as well, but I don't remember from the top of my head if we had such requests. I guess it will make sense to do it though, since following one approach for both variants kinda makes most sense rather than having different policies.

I'll work on preparing infrastructure for that.

[Kinqdos]

Sounds awesome thank you!