Hacker News Reader

Comment by nielsole | Hacker News Reader

Previous communication:

> If you don't upgrade to a paid subscription, Docker will retain your organization data for 30 days, after which it will be subject to deletion. During that period you will maintain access to any of your public images.

New communication:

> We’d also like to clarify that public images will only be removed from Docker Hub if their maintainer decides to delete them. We’re sorry that our initial communications failed to make this clear.

Given these statements directly contradict each other I am a bit surprised this is called clarification. It feels like they changed the actual strategy, not just the communication around it.

View on HN

(from Docker DevRel team)

> Given these statements directly contradict each other

Actually... they aren't contradictory. The organization data will be retained for 30 days and is subject to deletion. That data includes the teams, memberships, etc. But, it wasn't clear what we were going to do about the images. Keeping the public images is important as many other images build on top of them.

> It feels like they changed the actual strategy

We recognize it might feel that way, so apologies. But, that's part of where we are recognize it wasn't clear the technical details... we didn't talk at all about the images. After the feedback, we recognized this, so wanted to make that clear.

>Actually... they aren't contradictory.

They are. Your intent may not have been contradictory, but the messages received by everyone else were contradictory. You should own that if you are serious about doing better. Your intent doesn't really matter in these situations.

Yeah, really weird that after an apology announcement they’re still defending the original message at all. Not too hard to say “Yes, those messages contradict each other. The first one did not communicate our actual plan. The second message is a correction and clarification.”

It is important to understand that most corporations do not apologize, ever, unless there is a direct threat to cash flow.

This behavior is now demonstrated, it is the desired relationship, and it will be the baseline, all protestations aside.

The apology is meaningless. If this is not what you want, then take steps to limit the damage done to you, and do it now.

That's.... why they are saying it was poor communication.

They did in the OP link. To say now in comments "It's not contradictory" is not owning up to it being bad communication

What? That does not follow at all.

More cynically, the intent might be blaming image maintainers: since obsolete images that appear current are a problem, responsible maintainers will delete them before losing access; then Docker will be able to tell inconvenienced end users that the maintainers autonomously and unnecessarily decided to remove their images.

This...

>>>During that period you will maintain access to any of your public images.

What did this mean in that case? That the images will continue to exist but the maintainers cannot update them? They'll just become orphaned?

(from the Docker DevRel team)

"During that period" refers to the 30-day period. During that time, the images are accessible. After the 30-day period, they will still be pull-able, but not able to be updated.

>accessible

>pull-able

To any reasonable average person, these mean the same thing.

Absolutely not. For users, yes. For the person uploading/modifying the image, hell no.

So, any public image where the maintainer doesn't jump through hoops gets frozen in time, unable to be updated, and starts accumulating CVEs? This sounds worse than deleting the image.

Any smart FOSS maintainer will find alternate hosting...

> Any smart FOSS maintainer will find alternate hosting...

I think that’s obviously the point of the whole exercise — pony up or leave. They’re just doing it in an annoying manner

Can't believe how soon this announcement came after the redhat "we're killing centos support now, best of luck". It's pretty clear how this industry reacts to major support changes with no heads up.

This is an important implication that needs to be brought up in the FAQ explicitly.

In other words, the public repos are being archived. If I was a maintainer responsible for providing up-to-date and secure images, then I think it would indeed by my duty to delete them, if I am no longer able to update them.

> If you don’t upgrade to a paid subscription, Docker will retain your organization data for 30 days, after which it will be subject to deletion. During that time, you will maintain access to any images in your public repositories, though rate limitations will apply.

Specifically (emphasis mine):

> During that time, you will maintain access to any images in your public repositories

So, the logical conclusion, which literally everyone else on HN had, was that after that time you will lose access to images in your public repositories; access meaning "we can get to the image" in this context, because that's what people f-n care about.

Not to mention the other part, about how Docker will still have images available for pull that can't be changed, for which there is no way to "forward" user pulls elsewhere if the developer chose to not pay the fee; so in affect you're capturing their user base with old software and almost no way to know that.

"DevRel" at Docker failed this week. Just own up to it, take the hit, and don't be evasive. Evasiveness is shady and no one trusts that bullshit.

Delete them.

Keeping them read only is literally the worst solution. Old images that can't be updated and accrue security flaws, all while uninformed users see address still work and assume nothing needs to be changed.

Your corporation picked literally worst way to do it.

>> Your corporation picked literally worst way to do it.

I disagree. The worst way would be to make a blanket decision for all projects on their behalf.

This way they let the project maintainer decide.

For projects that don't get updated, it's better to leave them where they are.

For projects that are changing the maintainers can choose to delete (or move to a paid / OSS plan).

Choice is good, and giving that choice to maintainers is good.

The final act if goodness (and I'm not clear yet) is whether maintainers will be able to delete an image at some point in the future. Like say a year from now. Possibly by creating a paid account, and "reclaiming" that image.

Personally I agree that your advice to delete them may be the best option for most maintainers who have decided to leave. And they currently have the ability to do that.

Hence my assertion that your statement is incorrect.

You didn't address the issue of security. The problem with leaving it up to the projects is that projects won't necessarily respond, and we don't want the foundations of the next Mantis 26M rps botnet to get its start from PULL insecure:latest.

Deleting 'organization data' absolutely read that they would delete everything. Changing direction and back pedaling with a non-apology is borderline insulting.

I understand the need to make money as a company, but it really is biting the hand that fed messing with open source maintainers

They really think we're idiots!

We have learned that public images are NOT organization data!

With the organization data gone, will there be a way to update the retained images, like security fixes etc? If not, then this could become very dangerous.

Really, if they delete the org data and images can’t be updated, it might just be better to delete them all just to avoid these inevitable issues (maybe with a longer delay). Just rip the band-aid off and be done with it.

Marketing people try to explain away mistakes with doublespeak. Isn’t it grand? They keep digging deeper at this point.

"Actually" is not a great word to use in the context of an apology.

Relying on a free service for important work? Maybe they are right.

Silly us, I suppose we should stop relying on APT/RPM/what-have-you Linux package mirrors, NPM, NuGet, PyPi, Hex, RubyGems, Crates, ... too.

No. There's a huge difference between a volunteer driven organization and a for-profit company.

Their goals are completely different. The latter is not there to give you services. It's there to maximize shareholder value.

It's sad to see that HN can't even tell the difference anymore.

Neither npm nor NuGet are volunteer driven organizations. npm is owned by Github, NuGet is owned by Microsoft, and I'm sure that there are dozens of other examples behind many key pieces of free dev&ops infrastructure that are owned by for-profit companies.

Are they allowed to do it? Of course! Are we allowed them to call them out on their bait & switch tactics? Of course, what else are we supposed to do?

Just because something is common, like building a user base based on implicit promises and then pulling the rug once the service reaches critical mass, doesn't mean it should be accepted and normalized.

> npm is owned by Github

And GitHub is owned by Microsoft, duh. And they don't do this stuff out of the kindness of their hearts.

> what else are we supposed to do?

How about not falling for the same trap again and again instead?

> ... pulling the rug once the service reaches critical mass, doesn't mean it should be accepted and normalized.

Then don't sit on that rug.

You don't have to lecture me about the pitfalls of willingly relying on for-profit companies or the benefits of decentralization, but in the case of Docker we don't really have much of a choice unless you're suggesting that don't use it at all.

Images are published wherever the author decides that they're published and these changes are going to affect everyone who relies on an image that used to be hosted on Docker Hub.

We all rely on many free services and code. And, by the way, I'm a paying customer - I don't use their services but do this to support the pioneer!

I have no horse in this race, but fwiw, I can see how this mistake would be made honestly. Organization data could be easily refer to just the metadata of the organization, and depending on how the product is structured[1], could feel quite different from public images.

[1] Disclaimer: I don't know how the product is structured.

Can the images be updated after the organizational data is gone? If not, is there a security concern, since vulns are likely to be discovery in future?

Communication isn't about you meant, it's about what the person you're communicating to thought you meant.

If you are deleting the organizational data and effectively archiving [1] all the images, keeping only the option for public images to be pulled but not updated... then how will affected maintainers be able to delete their now out of date public images after the 30 day cut-off? You will have to retain enough of the organization data to allow that to happen.

Keeping the public images available in an archived state is okay for specific image references, but questionable for specific image tags and somewhat irresponsible for the `latest` tag. A `latest` tag that cannot be updated is ... worse than no `latest` tag.

Responsible maintainers that are unable to apply for open-source status or otherwise sponsor their usage of organization public repos should be advised to delete their public repos.

Responsible users of public images on Docker Hub need to have a way to determine which images will be affected, and which will continue to be maintained. Archiving the public repos gives an extended grace period, but users will still need to be prepared to notice if they end up using a now unmaintained, archived repo and migrate to alternative image sources.

[1] https://news.ycombinator.com/item?id=35188691

"somewhat irresponsible for the `latest` tag. A `latest` tag that cannot be updated is ... worse than no `latest` tag"

What's irresponsible is relying on a "latest" tag for updates.

It's not* just `latest` tags, it will also affect any other image tag.

If you've been referencing org/image:tag where tag=major-minor, and gets updated when there's a patch, then that's going to stop getting updated.

Without either the tag being deleted (and thus your pulls failing), or going out to find updates on that container - you may not notice that it's fallen out of date and the image/tag is no longer being updated.

With the entire organisation being removed from Dockerhub, it sounds like there's not even going to be a way for people to say "We've moved off Dockerhub, our images/source/etc is now over here".

You'll just have to search and hope you can find where it's moved to.

The irresponsible thing is making it so the tag exists, but the organization behind it cannot update it.

Let's take for example the "jenkins/jenkins:latest" image.

Jenkins is notorious for having security updates, so in 2 years, if the latest tag is still there and frozen, it will be an attractive nuisance, causing people to download insecure software...

That's what the parent comment is trying to say. It's irresponsible to leave the image that implies it's "up to date and secure" because it's "latest", but is really insecure, and the organization owning it cannot change anything about that without paying $$. It's basically holding users of the image hostage.

You missed his point. He's saying "latest is an anti-pattern". Which is correct. Everyone should be pinning to specific versions or semver to avoid being accidentally upgraded to a release with breaking changes.

Yes, obviously making existing tags immutable is bad. Nobody is disputing that.

There are exceptions though. I'm the kind of person that would pin Jenkins to latest even if it is an antipattern. I'm way more concerned about security flaws than a temporary CI breakage. So for me: Everyone should be pinning Jenkins to latest to avoid accidentally staying on a release with security holes.

You are not only auto pulling fixes bit also auto pulling new security holes though.

My take on Jenkins with all its plugins is that it need to be properly shielded from external access anyways.

You probably want to pin to at least a major tag to avoid auto-pulling breaking changes at any moment but still getting security updates.

is it?

sometimes I want a container running the latest version of something. maybe i'm integration testing my stuff against that release to make sure stuff still works. or maybe I'm hoping a bug was fixed and will version pin later.

i agree that production software should version-pin all the things, but latest still has a place.

> Actually... they aren't contradictory.

you're on the Docker DevRel team, why are you talking like this? why do you feel the need to be confrontational? not a good look.

Somewhere in Silicon Valley are the people who were passed over for this job, yelling at their phones. Maybe they should get a call back.

Face it, you're on heavy damage control and it just seems... untrustworthy.

So you’re going to continue to host images that have severe remote code execution exploits?

With no way for the person who posted them to ask people not to use them?

It appears that even after nonapology they still don't get the fucking problem.

The whole thing only needs docker infrastructure getting hacked because it used some of the now-orphaned containers to complete the shitshiw

I wonder what a court would think about who'd be legally liable there?

BigCo or GovDepartment gets popped via a known exploit against a fixed bug in an OSS project, but GitHub has prohibited the project from updating the explicable image they host without paying a ransom of $420/year?

> So you’re going to continue to host images that have severe remote code execution exploits?

That seems an great way to take some very significant reputation hits.

sooooooooooooooooo orgs that didn't want to upgrade are still left with users pinned to old address of the image with no option to push security updates?

I understand you are in a difficult position, but this is a bit absurd.

> During that period you will maintain access to any of your public images.

The only reason that sentence would be in there is if after that period you would lose access to the public images! And from Merriam-Webster, "access", verb, definition two: "to open or load (a computer file, an Internet site, etc.) a file that can be accessed by many users at the same time".

> it wasn't clear what we were going to do about the images.

No, it was quite clear; after the 30 day period we would not be able to pull the images. That's what the announcement said. It was not ambiguous. That may not have been the policy or what was intended to be announced, but the issue here isn't a lack of clarity.

(Also, letting the images stay accessible but disallowing any changes is only marginally better than just removing them, so the current policy - whether or not it's the same as the originally announced policy - is still terrible.)

I’m guessing they mean “write access.”

Write access is a subset of all access, so I don't think we can really argue that the plain meaning of the original statement was about removing write access.

But yes, a missing word is certainly a plausible explanation for how they issued a statement that meant the opposite of what they apparently intended.

But the original statement did not say all access, it merely said access:

> During that period you will maintain access to any of your public images

Assuming that the you in that sentence is the organization and not the general public (given the use of your organization earlier in the paragraph), the logical interpretation is that they meant write access here, and not all access -- since read access is not limited in any way to the you in that sentence.

Yes, I agree the original messaging was terrible. But claiming that the original can only have meant all access is not consistent with the wording of the announcement.

You are right, it's two different messages.

I always am annoyed by how companies apologize for the communication or the confusion arising after the communication. As if we, the public, didn't understand properly or are too dumb to understand what they tried to say. We understood perfectly and the _message_ was dumb, not the communication around the message. It doesn't feel like an honest apology.

Dude: "the message" is "the communication".

"No no no, the message in our contradictory communication is actually the message that you can interpret that contradiction with if you have this new piece of previously undisclosed information! How could you possibly have been confused by that? We are DevRel, we are communication professionals..."

rolls eyes OR, their marketing and DevRel departments and their engineering departments simply had a miscommunication; when it was realized, the present post was composed.

This kind of thing happens inside companies all the time, including the one you're probably working at right now.

No need to get up in arms over it.

People who are busy working aren't going to rush to HN to post about how they understood the announcement and are reacting as needed.

People who are bored (like me) will post rants and accusations.

I don't believe it was a miscommunication. Even if it was a company as important as Docker inc, mentioning DELETING containers requires some care and should raise some flags at any serious communications department.

This is not just the wrong date for a convention in the newsletter. What impact does it have on the ecosystem they've built? Some really serious projects use Docker and even if they have their own repositories can they be sure the software they rely on can keep publishing containers?

Even at the tiny startups I've worked on I'm asked to proofread any technical stuff they want to publish, I assume Docker does too.

This is why I believe that they changed what would happen after the pushback and are trying to hide that they changed.

In reality they were probably just going to disable access to updating all along and then maybe someday delete things, but didn’t want to say exactly that.

The thing is, if images are still accessible, then they still incur egress costs for Docker, thus negating the potential cost savings from this move.

So at best, they just tanked their reputation for... minimal cost savings?

Egress is (relatively) cheap and the amount of it will dwindle over time as the images become more and more "out of date".

Nomenclature nitpick: "deleting images", not "deleting containers". Images are what they host. Containers are running instances of an image.

No need to try and reframe or defend a bad decision. The should be held to account.

Both sound like "you won't be able to update them", so images sort of permanently squatted and growing tech debt, potentially vulnerabilities, etc. They should really allow for configuring the ":latest" tag to raise a 404 or something if this is what all that means.

By replying on a tag for your security you're opening yourself up to vulnerabilities.

Relying? I was assuming a 404 for "latest" might cause people to look into what happened with the image and find it's new home. Without locking them out of specific versions if they needed them for some reason.

Exactly ! I remember the original email mentioned deletion and now they say "we never said that".

Time to get rid of Docker in our world.

With what?

If you want actual reproducable, actual portable software, Nix. Otherwise there are countless other OCI runtimes, cri-o, containers, etc. Kubernetes doesn't even use Docker.

What a thing, docker. I can't get over the staying power it has had despite... Everything.

How do I run the ecosystem the docker already has with nix alone?

It's not just the runtime.

I'm not certain what "ecosystem" means in this context, but you can build docker images using Nix. It's actually pretty cool because the image only contains the runtime dependencies of whatever you throw in the container. No package manager or build system is included. I've only tinkered with Nix, nothing in my professional life, so YMMV.

I'm super interested in the ecosystem you mean here. I'm assuming that you mean ecosystem around images like kubernetes, ECS, etc like the other commenter guessed?

If so, I think Nix being able to create docker images addresses that specific concern.

Can nix run images created with docker?

Yes.

See https://nix.dev/tutorials/building-and-running-docker-images

Or do you mean run as in "use docker image(s) within a nix expression". Like if you have a webapp with a nix devshell but want to start the docker postgres container for development?

You can do that too, yes.

I can easily install many apps hosted at the Docker hub but how would I achieve that without Docker hub, unless everyone starts hosting things elsewhere but that'll take a good while assuming the community's consensus is to ditch Docker altogether.

> I can easily install many apps hosted at the Docker hub but how would I achieve that without Docker hub,

I'm sorry, I don't understand what you mean.

Podman is pretty good, and more or less a drop-in replacement.

Yep, already wrote an internal guide for my whole team to move away from docker into podman+quay.io by the end of next week.

Works like a charm on our macbooks, very neat.

Even if we need to pay, I’m looking for alternatives not Docker Inc. - There is only so much you can take.

I don’t want to rely on them anymore.

Any chance of seeing a version of that guide outside of your organization?

Someone on lobste.rs mentioned quay.io (maintained by redhat) as an alternative to dockerhub. Anyone have any experience with it?

It started as a CoreOS project and for a long time it was the only ebterprisey registry, and it included security scanning. Had some availability issues some time ago, but AFAIK today it's pretty good.

The software is nice, if looking to run your own - I'd recommend it over the typical Docker-provided incantation

Way more enterprise appropriate, for example - granular control on caches

Given the CentOS shit, I'm not convinced jumping from Docker Inc to RedHat is appropriately mitigating the risk of a corporate rug pull once they've decided its time for the next step in their enshittification plan...

im looking forward to hipster posts about compiling and running your stack directly on a machine. probably one, and it'll be faster. that'll be great

Nah, Docker/containers are here to stay. But Docker, Inc. isn’t.

No no no, you build your stack, transpile it to WASM, and run it on your user's phones! WebRTC to run a distributed shared database across every phone that's not behind NAT! No servers. No databases. No electricity bills. Your backend hardware fleet automatically updates itself every couple of years _and pays_ for it itself!

Wait, that's hipster now? Isn't that a graybeard thing?

If you run a company wouldn't it be cheaper to just pay. This can't be worth the trouble changing everything

Sure.

This is just a big "fuck you" to non company supported open source projects, as it turns out even ones labelled "sponsored css" on Docker Inc's own website.

Which are all clearly insignificant and unimportant, dumb little command line utilities and libraries like, say, curl...

https://github.com/docker/hub-feedback/issues/2314#issuecomm...

Hi, ah... perhaps I'm an idiot for asking, but why does a near-ubiquitous system utility like curl need to be installed via a container? Is it not available on something like Alpine... and if so, then maybe it should be?

It's like saying I have to install `vi` via Docker... please don't tell me vim has a Docker hub repo too...

Please share a copy of that email.

Docker is sunsetting Free Team organizations

Free Team organizations are a legacy subscription tier that no longer exists. This tier included many of the same features, rates, and functionality as a paid Docker Team subscription.

After reviewing the list of accounts that are members of legacy Free Team organizations, we’ve identified yours as potentially being one of them.

If you own a legacy Free Team organization, access to paid features — including private repositories — will be suspended on April 14, 2023 (11:59 pm UTC). Upgrade your subscription before April 14, 2023 to continue accessing your organization.

If you don’t upgrade to a paid subscription, Docker will retain your organization data for 30 days, after which it will be subject to deletion. During that time, you will maintain access to any images in your public repositories, though rate limitations will apply. At any point during the 30-day period, you can restore access to your organization account if you upgrade to a paid subscription. Visit our FAQ [1] for more information.

[1] https://web.docker.com/rs/790-SSB-375/images/privatereposfaq...

This is the exact quote that was already up-thread of here, and they absolutely are not claiming they "never said that"; instead, they are clarifying that "organization data" does not include "public images", and while that's confusing, I can appreciate why they didn't think it would be and--lo and behold--they are publicly apologizing for being so confusing and taking the hit for having done so.

Its the very next sentence after that one that they are claiming has been practically universally "misunderstood".

"If you don’t upgrade to a paid subscription, Docker will retain your organization data for 30 days, after which it will be subject to deletion. During that time, you will maintain access to any images in your public repositories, though rate limitations will apply."

The cynical devil on my left shoulder is telling me "Some smartass in an emergency meeting noted the ambiguity in that second sentence, and suggested lets just claim that 'During that time you will maintain access to any images' did not actually mean it's obvious implication that 'after that time you will no linger have access to any images' and this is all just a big misunderstanding" - and that how we ended up with this new "clarification".

The even more cynical devil on my right shoulder is telling me some actively evil asshole intentionally wrote that ambiguous sentence to give themselves a 'get out of jail card' in case complaints went viral...

Reminds me of the gaslighting of the D&D community recently around changes to the license there.

It’s like watching a five year old who’s convinced he can fool his parents.

sorry what d&d license change?

WotC tried to retroactively revoke an open gaming license that had been in widespread use since 2002. They had a legal theory why they could do this, but that theory contradicted quite a few public statements they had made on record. IP lawyers had very mixed opinions.

Many TT-RPG players enjoy reading rules carefully and figuring out fun ways to "exploit" them. So everyone jumped on WotC's changes and dissected the implications. And many companies in the larger ecosystem quickly announced plans to ship their own games competing with D&D.

WotC decided to back down and to just use Creative Commons, which largely resolved the immediate issue.

My first reaction to the news was "ok, net positive, unmaintained images will get cleaned up and break builds, and fewer people will then be bit by vulnerabilities in unknowingly used abanoned layers". But I guess not?

That depends on what "organization data" means. Does that phrasing cover the images or just the existence of the organization in Docker (i.e. deleted organization)?

> During that period you will maintain access to any of your public images.

Pretty unambiguously means "after that period you may not have access to any of your public images".

Isn't that like a service like Github saying 'you will maintain access to any of your public projects' as in administrative access to one's own projects. After that period, you are no longer the owner of that repo and you no longer have "access". So I can still clone your github project but alas you no longer can commit to it.

https://docs.docker.com/docker-hub/orgs/

https://hub.docker.com/orgs

Doesn't sound like it to me. If they meant "administrative access" they should have said "administrative access". They didn't, they just said "access" which unambiguously means just "access". Would've been very easy for them to make a one word correction somewhere in the dozen or so people who should have read this before it went out. But they didn't, they just said "access". If they wanted unambiguous meaning, they could have easily just said what they meant.

Methinks that's exactly what they did

Well, methinks otherwise. Lack of access does not mean files deleted. Organization data deleted means account deleted. Contention here was the claim that they have done a uturn but they never said they will delete images. This entire somewhat useless thread is about whether lack of access actually meant images deleted. (Administrative is a word that I used in my comment and a red herring to pick on, quite frankly.)

> They didn't, they just said "access" which unambiguously means just "access".

Not only that, they said access to your public images. Not "access to your account" or "access to your project". They explicitly mention "any images in your public repositories" as a thing that you will "maintain access" to "during that time".

Reply on news.ycombinator.com