search

nextcloud / docker

⛴ Docker image of Nextcloud
https://hub.docker.com/_/nextcloud/
GNU Affero General Public License v3.0
6.02k stars 1.83k forks source link

remove 18.0.5 from docker hub #1145

Closed r2evans closed 4 years ago

r2evans commented 4 years ago

nextcloud.com states:

EDIT: Please hold off on updating to 18.0.5, there is a bug in the right sidebar that will be fixed with a 18.0.6 as soon as possible.

image

But it is still available on hub.docker.com:

image

(I'm assuming that if the bug is significant enough to post a "please hold off" message on the blog page, then it's significant enough to deter new updates.)

rwese commented 4 years ago

Well, my docker setup has happily updated it's image to 18.0.5 already, so at least new users checking it out would be helped.

J0WI commented 4 years ago

We cannot remove a version that has already been released. We can just upgrade to 18.0.6 and that's happening in https://github.com/docker-library/official-images/pull/8149. As a workaround you can use the 18.0.4 or the stable tag to receive delayed updates. However, if you've already upgraded to 18.0.5 it's risky to perform a downgrade.

r2evans commented 4 years ago

"cannot remove a version that has already been released"? Perhaps I'm over-thinking it, but ... hub.docker.com does not force you to keep tags, they can be removed at will. What you're suggesting is not a technology limitation (e.g., https://stackoverflow.com/a/60112300), is it a policy decision to continue to allow installation of a known-faulty release?

I understand that normal release flow may mean that the tags available on hub.docker.com are not up-to-the-minute with the tarball/zipfile downloads available from your servers. However, the "please hold off" is clearly an exceptional event that requires manual overriding of normal flow:

  1. Normal path: release, allow CI/CD to package-ize, container-ize, upload, and tag.
  2. Oops, big bug found:
    • [x] manually add note to the website: "please hold off"
    • [ ] manually remove the tarball from the releases and download directories
    • [ ] manually remove tags from hub.docker.com

I'm inferring from the NC response that the "please hold off" is really over-stated, since other than the note, there has been no attempt to preclude auto-installers or manual installation of the known buggy version.

(The problem with your "workaround" is that it is only relevant if you preemptively distrust the autoupdate process. Otherwise, the update would already have happened since the image is still available ... and in fact, still the highest 18 available. Further justiifed as a problem when you say downgrading is not recommended ... which while perfectly believable, is more justification for taking down the known bad images.)

J0WI commented 4 years ago

hub.docker.com does not force you to keep tags, they can be removed at will.

Normal path: release, allow CI/CD to package-ize, container-ize, upload, and tag.

The release process for "official images" is not the same. The "official library" stores the commits and tags for all official images and we cannot "force push" the whole library (technically you could, but it would also break many other things). It's also a bad idea to do this for the nextcloud/server repo or to remove already released downloads. This would break a lot of things downstream, like reproducibility or packagers that manually backport patches.

Whatever we can do right now is not faster than just packaging 18.0.6. Every change requires the same review an build process as https://github.com/docker-library/official-images/pull/8149 does. The update will fix the bug and AFAIK it does not cause any irreversible damage.

r2evans commented 4 years ago

Okay, thanks! What do other applications/services do? This problem is certainly not unique to NC, and there are definitely times when a specific version is just "removed from availability" (or just visibility). I recognize that CI/CD makes doing this a challenge (since once deleted it might just be packaged again). I have also seen a repo tag (not a commit, not an image, no artifacts) removed, which migrates downstream (e.g., to hub.docker) making it difficult to find "that version of the app" in the normal ways.

Is this just a "level of effort" thing? I don't want to keep pushing if it's just "we know how to do it, and this bug is not critical enough to do that", in which case I'll drop it. If instead it were a "gaping security hole that had known zero-day exploits" (not that NC would allow that to happen), then I'd expect herculean efforts to remove any and all possible downloads of that specific release. If even that's impractical or not possible, then I suggest the release methods might need a tweak.

J0WI commented 4 years ago

I'd always keep every version available. This makes it transparent and you can also reproduce the issue later. Otherwise we'd also have to remove all EOL versions and people may wonder why there are missing numbers in the version history. I think this is also what every other free software project does. E.g. you can still download a heartbleed vulnerable version of OpenSSL or a Linux Kernel from 1994.

I'm not aware of any special announcement about critical bugs or security fixes before the public release. As soon as a new release is public, we can update the image ourselves. In the case of critical security fixes, we can ping the heroes from the docker library to prioritize the review process. A zero-day exploit means, that the bug is already exploited in the wild before the vendor becomes aware of it. That's nothing we can prevent.

r2evans commented 4 years ago

Your point about transparency is well-taken, thank you for that perspective.