search

Unidata / thredds-docker

Dockerized THREDDS
https://hub.docker.com/r/unidata/thredds-docker
BSD 3-Clause "New" or "Revised" License
36 stars 28 forks source link

Add "latest" tag to docker hub #283

Closed swainn closed 1 year ago

swainn commented 1 year ago

To report a non-security related issue, please provide:

This issue is related to the tagging approach on the docker hub repository for the thredds-docker. It appears that you are only maintaining tagged images for the release version (currently 5.4) and the next version snapshot (currently 5.5-SNAPSHOT). Since you remove older tagged versions and there isn't a latest tag, it makes it difficult to maintain software that is referencing the thredds-docker. For example, as soon as 5.5 is released I'm assuming that 5.4 will be removed, which will brake all of our systems referencing the 5.4 image. If you had a latest tag, we could just reference that and wouldn't need to update every time you release a minor update. Will you consider adding the latest tag?

If you have a general question about the software, please view our Suggested Support Process.

julienchastang commented 1 year ago

The reason for discontinuing the latest tag is due to potential confusion that can arise from not knowing which version is actually running. Additionally, the latest tag can be a vector for insecure and unvetted packages, which can compromise the security of any systems that rely on it. We recently experienced an issue related to this and have taken steps to address it.

We understand that the latest tag is convenient, but we have decided not to bring it back due to the potential aforementioned risks associated with it. We recommend using specific version tags to ensure that you have a stable and secure image.

Note that stable image tags ( e.g., unidata/thredds-docker:5.4) are not necessarily static and must be updated from time to time because of upstream changes in Tomcat, Java, Ubuntu, etc. that must be incorporated. While this may sound confusing, this is the convention in Dockerland.

For example, as soon as 5.5 is released I'm assuming that 5.4 will be removed, which will brake all of our systems referencing the 5.4 image.

This is indeed true, if we discover that the older version has a security related issue. Again, older image tags with potential security vulnerabilities were recently a problem for us and we've had to remedy the issue.

Tsubashi commented 1 year ago

I think I agree with @swainn on this one. While I agree that running a latest tag in production is not a good idea, I feel that it is super useful in a development context. Rather than cluttering up a commit history with endless bumps, developers can pull latest and see when upcoming changes are going to need additional work. It seems like avoiding unexpected changes should be a decision that should be made on a per-use basis, rather than a whole package level.

Note that stable image tags ( e.g., unidata/thredds-docker:5.4) are not necessarily static and must be updated from time to time because of upstream changes in Tomcat, Java, Ubuntu, etc. that must be incorporated. While this may sound confusing, this is the convention in Dockerland.

Maybe I am misunderstanding something. Wouldn't having tags that change contents without any visible indication also be a vector for unvetted packages and unanticipated problems? Yes, a lot of projects add a tag for major and sometimes even minor versions that change when newer patch releases are made, but most also include very specific tags for individual builds that don't change.

I think the core of the issue is that, as a user of the image I don't want to worry about wether the image will be there or not. I'd like to be able to point to a latest or 5 tag when developing and have it always point to an image. At the same time, I'd like to know exactly what version is running in production, and would feel much better pointing to a 5.4-tomcat8.4 or some such specific, non-changing tag.

julienchastang commented 1 year ago

For various reasons, if anyone participating or observing this thread wishes to continue the discussion, it would be best to contact me directly through my UCAR/Unidata email.