It's good to hear that it will be fixed, but it's also troubling that a front-facing security issue took a #1 HN post, followed by debate in the comments before Docker recognized it.
That's a bit disingenous. The CLI clearly makes a security claim here, and you know very well that users will take it as one.
I'm all for "working on ways to make image distribution more secure", but making security claims in the CLI when said security does not exist yet is -- assuming good faith -- a security bug in the user interface that should be fixed.
> Let's be real here. If Docker was 'just' an open source project, it would move at 50% of the pace and security issues like this would still not be solved.
That's wild speculation, and the elephant in the room (Linux), while a different beast, is a pretty strong counterexample for how being 'just' open source oesn't doom you to being slow or insecure.
> It's crazy to assume that if it were an open source project it would somehow get the core right faster or not expand on its ambitions.
I don't think it's crazy at all. A (say, community funded) purely open source project has no distractions and has nothing to do but to get the core right. It also has no incentive or reason to expand its ambitions.
Which, if you put the pieces together, clarifies that the purpose of new Docker features is to lasso in fragmentation and make sure you're going to buy their vCenter/vSphere rather than any alternative.
This also clarifies why things like Rocket are the biggest existential threat facing Docker Inc., and why the mud is being slung.
That one seemed pretty ridiculous to me as well. If your project's direction is constant but your user's understanding is changing, then either you're failing to communicate or (worse) your product is actively forsaking its users.