Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mainline images shouldn't be tagged the same way as stable ones #905

Open
Elanis opened this issue Jul 4, 2024 · 5 comments
Open

Mainline images shouldn't be tagged the same way as stable ones #905

Elanis opened this issue Jul 4, 2024 · 5 comments

Comments

@Elanis
Copy link

Elanis commented Jul 4, 2024

One of the multiple ways to avoid long-term CVE and bugs in my infrastructure is to use version-tagged Docker images along with tools such as Dependabot or Renovate bot, these bots can automatically open pull requests to be able to get the latest nginx (or whatever image you're using) version.

Docker images versioning strategy use some semver-related principle where stable versions are of the form X.Y.Z (sometimes suffixed depending on the flavor), and unstable versions can usually be suffixed with some -rcX or -betaX.

Here, I (we) have an issue with Nginx since mainline and stable versions are tagged similarly (see 1.26.1 and 1.27.0).
On standard package managers, we usually wait for the version to be stable to push it.

But on docker, we can unexpectedly misunderstand a version tag as stable while actually, it's a mainline version. And that's what happened to me with 1.27.0 (thus why I am writing this issue).
This is a security and bug-creating issue since the mainline version shouldn't be confused with stable versions.

I propose to tag the next mainline version with a specific suffix such as 1.27.0-mainline or 1.27.0-unstable (Or 1.27.0-alpine-slim-unstable instead of 1.27.0-alpine-slim) to prevent people being confused and prevent automated systems to suggest updates to unstable versions of the software.

I'm open to discussing this issue, of course, or finding alternative ways to solve it 😄 (while still using versioned tags and not :*stable* tags)

@Elanis
Copy link
Author

Elanis commented Jul 4, 2024

One example: Dysnomia-Studio/dysnomia-website#13

@oxpa
Copy link
Collaborator

oxpa commented Jul 4, 2024

@Elanis would having something like http://version.nginx.com/nginx/stable help you? It has the latest version for stable (and mainline, and some other products) available so you can pull an update as soon as it is available.
It's not quite with docker tags though

@Elanis
Copy link
Author

Elanis commented Jul 4, 2024

Hi @oxpa,

It wouldn't be a solution indeed, because that would mean neither me nor the bots know which version is currently deployed.
What I need is, is the bot (or myself), to be able to read the dockerfile and see immediately if another stable version is available.

Usually (for most images), you would take the most recent tag. But here, you would take 1.27.0, which means you would update to a non-stable version. Which is problematic imo

I hope this is more clear :)

@yosifkit
Copy link
Contributor

yosifkit commented Jul 9, 2024

I think this is something to fix in Dependabot and Renovate bot to not treat Nginx as semver. Nginx doesn’t use semver but still does Odd-Even Versioning: odd-numbered releases are “development” and even-numbered are “LTS”.

You can also see the other tags for the same image on the Docker Hub page: https://hub.docker.com/_/nginx/#:~:text=Supported%20tags%20and%20respective%20Dockerfile%20links

1.27.0, mainline, 1, 1.27, latest, 1.27.0-bookworm, mainline-bookworm, 1-bookworm, 1.27-bookworm, bookworm⁠
...
1.26.1, stable, 1.26, 1.26.1-bookworm, stable-bookworm, 1.26-bookworm⁠

@Elanis
Copy link
Author

Elanis commented Jul 10, 2024

I didn't know Nginx was following odd-even versioning. Thanks for the information!

Though, I still think this is very misleading for humans and bots.

I should be able to be careful about that now, but I keep this issue open for other peeps who may run into the same problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants