Please remove openSUSE from the official library

[sysrich]

As much as it is nice to have the attention produced by having openSUSE in the official library, the reality is that none of the images on https://hub.docker.com/_/opensuse/ are valid offerings of the openSUSE Project

The official library curation process has proven to be far too slow for the actual rate of change of openSUSE Tumbleweed and Leap, and issues like #527 which hoped to rectify the situation have gone unanswered and unresolved for years

The images at https://hub.docker.com/r/opensuse/ are the only valid source of truth for valid openSUSE images, but this is not well reflected on hub.docker.com, with searches prioritising the invalid images as 'official'

The status quo is causing serious practical problems for users, with anyone using opensuse:tumbleweed getting an image that is phenomenally out of date and potentially vulnerable compared to opensuse/tumbleweed

As Chairman of the openSUSE Board I am also concerned about the Trademark and Copyright implications of Docker Hub redistributing out-of-date and unsupported openSUSE images as "official".

Therefore please can the openSUSE images be removed from the official library?

[tianon]

It's a little bit harsh to blame us open source maintainers for the outdated images there (so I'd appreciate if we toned down the heavy-handed wording here; we're all doing our best ❤️) -- our process turned out to not be a good fit for the openSUSE image maintainers (which as far as we understand, are representing openSUSE appropriately while maintaining that image), which is what led to docker-library/docs#1224 (which is where the notice at the top of https://hub.docker.com/_/opensuse/ came from). From the looks of the deprecation notice that @Vogtinator wrote in that documentation update, the opensuse:42.3 image should've still been receiving updates until June 30, 2019, right?

If the deprecation notice is considered insufficient and the image maintainers agree, we would be happy to remove the tags on that repository, which I believe is probably the best compromise for the user experience we could offer -- if we delete the repository completely, users who are currently using opensuse:xxx won't have anywhere to look for why it's gone or where it went, where if we just delete the tags, the user experience of trying to pull the images is the same (Error response from daemon: manifest for opensuse:xxx not found), but the Hub page would remain with the pointer to https://hub.docker.com/u/opensuse/ so users can figure out what they need to do to adjust.

cc @flavio @jordimassaguerpla @davidcassany @Vogtinator

(Just to be explicitly clear, no matter which way we go here, if we delete artifacts the user experience changes to Error response from daemon: manifest for opensuse:xxx not found, which isn't great, but at least gives users some indication that they need to adjust something, and IMO leaving the empty repo up is a reasonable way to help guide those users to the appropriate replacement.)

We should also update the "short description" to include the deprecation note so that it's more obvious both in the Hub web UI search and via docker search that this image is no longer maintained. How does "DEPRECATED; please see https://hub.docker.com/u/opensuse/ instead" sound as a replacement for the current "This project contains the stable releases of the openSUSE distribution." tagline?

It is absolutely not our intention to misrepresent openSUSE in any way (quite the opposite, really), so we apologise for any confusion or trouble this may have caused and hope we can find an amenable solution to get users on the right track here. ❤️

[Vogtinator]

It's a little bit harsh to blame us open source maintainers for the outdated images there (so I'd appreciate if we toned down the heavy-handed wording here; we're all doing our best heart)

I agree that the issue was worded a bit too harsh - I'm sure we can find a good compromise that works well for all sides (docker-library, openSUSE and users).

-- our process turned out to not be a good fit for the openSUSE image maintainers (which as far as we understand, are representing openSUSE appropriately while maintaining that image),

Correct, but the process (which mangles binaries, so they technically aren't provided by openSUSE anymore) is not the only issue here. The "vulnerability scan" is severely misrepresenting our images as it does hard comparisons against RedHat package versions, resulting in "red" state for all of our tags currently.

which is what led to docker-library/docs#1224 (which is where the notice at the top of https://hub.docker.com/_/opensuse/ came from).

Right, but unfortunately this PR is not enough - the clearly marked as deprecated image does not show up on any other page, which means that "opensuse" is still the first result when searching for "opensuse" and labeled with "official".

From the looks of the deprecation notice that @Vogtinator wrote in that documentation update, the opensuse:42.3 image should've still been receiving updates until June 30, 2019, right?

Correct - so I'd prefer if that is still reachable until EOL, to prevent user disruption.

If the deprecation notice is considered insufficient and the image maintainers agree, we would be happy to remove the tags on that repository

That means https://hub.docker.com/_/opensuse/ will no longer show anything, right?

We should also update the "short description" to include the deprecation note so that it's more obvious both in the Hub web UI search and via docker search that this image is no longer maintained. How does "DEPRECATED; please see https://hub.docker.com/u/opensuse/ instead" sound as a replacement for the current "This project contains the stable releases of the openSUSE distribution." tagline?

IMO that's still insufficient as long as it turns out to be the first result on the search result page. It's a good first step though.

What I would see as the best option is to hide the entire opensuse repo from the official library on the hub web pages, but still make the tags available through downloads. It's unfortunate that there's no way to tell users doing a simple docker pull opensuse that it's not not the image they wanted, but until EOL of 42.3 that's IMO acceptable.

[tianon]

Thanks for being open with us. ❤️ A lot of this is more issues with the Hub (and not necessarily things we can fix directly), but I'll do my best to address each point more directly. 👍

The "vulnerability scan" is severely misrepresenting our images as it does hard comparisons against RedHat package versions, resulting in "red" state for all of our tags currently.

We totally agree (see https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-so-many-cves for our FAQ entry that attempts to combat this question for our users as best we can), although that's not something we have any control over -- that's a Hub feature. 😞

It would probably be worthwhile to open an issue with Docker's support to perhaps get their security scanner updated to at least detect SUSE separately so they can disable their scans?

the clearly marked as deprecated image does not show up on any other page, which means that "opensuse" is still the first result when searching for "opensuse" and labeled with "official".

Right, that's what I was trying to help overcome with the suggestion for updating the short description as well, since that shows up in all search places and would make the deprecation much more obvious than it is now. 😅 (More on this below.)

Correct - so I'd prefer if that is still reachable until EOL, to prevent user disruption.

Totally sane -- have there been package updates in openSUSE 42.3 that would be worth incorporating in updated bits on that tag? If so, anything I can do to help with that? (If not, feel free to ignore. 😅❤️)

That means https://hub.docker.com/_/opensuse/ will no longer show anything, right?

That would mean we can update that image description to something more explicit/helpful for directing users (if the current notice is deemed insufficient), and yes, https://hub.docker.com/_/opensuse?tab=tags would then be empty. We could start by removing everything except the still-supported opensuse:42.3 tag -- does that sound reasonable? Should I go ahead and remove those other tags now? (In other words, do you feel like this is reasonable enough for me to do, and that the current description on the image is good enough to help users find what they should be using instead when they run into issues trying to pull the removed tags?)

IMO that's still insufficient as long as it turns out to be the first result on the search result page. It's a good first step though.

What I would see as the best option is to hide the entire opensuse repo from the official library on the hub web pages, but still make the tags available through downloads. It's unfortunate that there's no way to tell users doing a simple docker pull opensuse that it's not not the image they wanted, but until EOL of 42.3 that's IMO acceptable.

I'm not aware of any Hub features that would allow hiding a repository but still allowing it to be pullable (nor do they support any kind of redirection that I'm aware of), and I think hiding the repository would still make the user experience for users looking for the old opensuse image to figure out what happened more difficult, right?

Basically what I'm proposing is that we turn https://hub.docker.com/_/opensuse into essentially an old fashioned "landing page" for the https://hub.docker.com/u/opensuse images, since that's the best we can do. Then when users try to rebuild or recreate things based on opensuse:xxx and get the 404 message, they'll hit up https://hub.docker.com/_/opensuse to try to figure out what's going on and see what they should be using instead.

IMO this gives us a decent balance of getting rid of these old artifacts and helping users find what they really want to be using instead. Does that make sense?

[Vogtinator]

Thanks for being open with us. A lot of this is more issues with the Hub (and not necessarily things we can fix directly), but I'll do my best to address each point more directly.

The "vulnerability scan" is severely misrepresenting our images as it does hard comparisons against RedHat package versions, resulting in "red" state for all of our tags currently.

We totally agree (see https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-so-many-cves for our FAQ entry that attempts to combat this question for our users as best we can),

I just read the FAQ and it doesn't even mention "false positives" at all.

although that's not something we have any control over -- that's a Hub feature.

It would probably be worthwhile to open an issue with Docker's support to perhaps get their security scanner updated to at least detect SUSE separately so they can disable their scans?

AFAIK that already happened several times a while ago and nothing has happened. I don't expect any progress here :-/

the clearly marked as deprecated image does not show up on any other page, which means that "opensuse" is still the first result when searching for "opensuse" and labeled with "official".

Right, that's what I was trying to help overcome with the suggestion for updating the short description as well, since that shows up in all search places and would make the deprecation much more obvious than it is now. (More on this below.)

Correct - so I'd prefer if that is still reachable until EOL, to prevent user disruption.

Totally sane -- have there been package updates in openSUSE 42.3 that would be worth incorporating in updated bits on that tag? If so, anything I can do to help with that? (If not, feel free to ignore. )

Nothing security related AFAICT, so the current image should be fine.

That means https://hub.docker.com/_/opensuse/ will no longer show anything, right?

That would mean we can update that image description to something more explicit/helpful for directing users (if the current notice is deemed insufficient), and yes, https://hub.docker.com/_/opensuse?tab=tags would then be empty. We could start by removing everything except the still-supported opensuse:42.3 tag -- does that sound reasonable? Should I go ahead and remove those other tags now?

Not just yet - we should try to make the description complete before users want to look up what happened.

(In other words, do you feel like this is reasonable enough for me to do, and that the current description on the image is good enough to help users find what they should be using instead when they run into issues trying to pull the removed tags?)

The current (short) description isn't good enough - some still think that the "library/opensuse" image is the correct one to use. How can it be changed?

I copied all tags from library/opensuse into opensuse/archive and it probably makes sense to redirect there for those who still use the old images for some reason.

IMO that's still insufficient as long as it turns out to be the first result on the search result page. It's a good first step though.
What I would see as the best option is to hide the entire opensuse repo from the official library on the hub web pages, but still make the tags available through downloads. It's unfortunate that there's no way to tell users doing a simple docker pull opensuse that it's not not the image they wanted, but until EOL of 42.3 that's IMO acceptable.

I'm not aware of any Hub features that would allow hiding a repository but still allowing it to be pullable (nor do they support any kind of redirection that I'm aware of), and I think hiding the repository would still make the user experience for users looking for the old opensuse image to figure out what happened more difficult, right?

I agree.

Basically what I'm proposing is that we turn https://hub.docker.com/_/opensuse into essentially an old fashioned "landing page" for the https://hub.docker.com/u/opensuse images, since that's the best we can do. Then when users try to rebuild or recreate things based on opensuse:xxx and get the 404 message, they'll hit up https://hub.docker.com/_/opensuse to try to figure out what's going on and see what they should be using instead.

IMO this gives us a decent balance of getting rid of these old artifacts and helping users find what they really want to be using instead. Does that make sense?

Yes, sounds like a plan. @sysrich, what do you think?

[sysrich]

@Vogtinator 👍 sounds like a good plan to me too

Thanks ❤️

[tianon]

I just read the FAQ and it doesn't even mention "false positives" at all.

If you've got some suggested wording, I'd be happy to review/carry it in -- it was originally intended to, but I think that point got lost along the way (since there is a lot of info there / ways a scanner like that can be misleading or outright wrong). 😅

The current (short) description isn't good enough - some still think that the "library/opensuse" image is the correct one to use. How can it be changed?

The best way would be a PR against https://github.com/docker-library/docs/tree/master/opensuse (specifically deprecated.md, content.md, and README-short.txt), but if you wanted to just leave your desired wording/changes in a comment here, I'd be happy to carry those through there and get them up. ❤️

[Vogtinator]

I just read the FAQ and it doesn't even mention "false positives" at all.

If you've got some suggested wording, I'd be happy to review/carry it in -- it was originally intended to, but I think that point got lost along the way (since there is a lot of info there / ways a scanner like that can be misleading or outright wrong).

Here: docker-library/faq#4

The current (short) description isn't good enough - some still think that the "library/opensuse" image is the correct one to use. How can it be changed?

The best way would be a PR against https://github.com/docker-library/docs/tree/master/opensuse (specifically deprecated.md, content.md, and README-short.txt), but if you wanted to just leave your desired wording/changes in a comment here, I'd be happy to carry those through there and get them up.

Ah, that's where the short description is coming from - PR is on the way: docker-library/docs#1420

I just noticed another weirdness on the hub: It always says that the "library/opensuse" image was updated "an hour ago" even if this isn't remotely true. Why is that and can anything be done against it?

[tianon]

I just noticed another weirdness on the hub: It always says that the "library/opensuse" image was updated "an hour ago" even if this isn't remotely true. Why is that and can anything be done against it?

Unfortunately not something we have any insight into (although we've reported it to the Hub folks with no response so far) -- as far as I can tell, it only shows glitched like that on search though; if you query the unofficial Hub API (https://hub.docker.com/v2/repositories/library/opensuse/), you get "last_updated": "2018-12-20T01:22:59.382879Z" which is more accurate and timestamps on https://hub.docker.com/_/opensuse?tab=tags appear to be more accurate too. 😞

[tianon]

@Vogtinator are we ready to move forward on removing the remaining tags here now, or should we continue to wait a bit?

[Vogtinator]

@tianon I don't see any reason to wait longer, you've got my permission to go ahead.

[tianon]

docker-library/docs#1518 is updated/pushed and the final remaining tags are now removed 👍 ❤️