3 ms·

I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conf

I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conflated in various comments.) Use your own registry by specifying the domain first `myregistry.example.com/repo/image`; an unadorned `repo/image` being globally reserved as shorthand for `registry.docker.io/repo/image` seems fine. Allowing overriding the meaning of `repo/image` would be a support nightmare for both moby and internal IT, just use qualified names.

light_hue_1 5y ago
This suggestion is a security nightmare! Anyone is one typo away from installing random junk from the internet on your machines. No one should be using docker in production while it can connect to a public registry where you have zero control of its contents.
- infogulch 5y ago
  Did you read my comment? Because I can't find any interpretation of your response that makes sense assuming you comprehend the actual content of my statements.
  - light_hue_1 5y ago
    I did read the comment. And I comprehended the content of the statements. And I'm scared that this obvious security risk isn't horrifying to you. > I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conflated in various comments.) Use your own registry by specifying the domain first `myregistry.example.com/repo/image`; an unadorned `repo/image` being globally reserved as shorthand for `registry.docker.io/repo/image` seems fine. Allowing overriding the meaning of `repo/image` would be a support nightmare for both moby and internal IT, just use qualified names. Literally anyone in your company can forget to say `myregistry.example.com/` at any moment. And then your whole infrastructure runs on some random image that you didn't vet. You're a typo away from having your machines owned, your entire infrastructure falling over, your data being exposed to the anyone. This is no way to live and it's no way to run a company.
kbenson 5y ago
I believe that was acknowledged in some of the pull requests, and also a problem with correctly using credentials for repositories and various solutions were proposed (see one of my other comments for links). Ultimately, the reason given in the pull requests I saw was along the lines of "it will fracture the namespace and hurt the community". Disabling all registries except for those whitelisted and requiring full names for those would probably have been sufficient for this problem, and not fractured the community IMO. There's a difference between what you allow in dev and what you allow in production, where you should have a chance to vet all new requirements and ensure they are appropriate. It's just unacceptable for some organizations to allow stuff to be as ad hoc as that, as much as Docker might want to inject itself into their processes at that level.
- infogulch 5y ago
  > Disabling all registries except for those whitelisted and requiring full names for those would probably have been sufficient for this problem, and not fractured the community IMO. Yes this is what I was getting at. You don't need to override the meaning of image names, you just need to be able to disable registries outside your control and prefix all your images. It's like an additive vs subtractive blindness effect that caused people to miss this solution.
  - kbenson 5y ago
    It wasn't missed, from what I saw in the issue and pull request. It was offered, and ignored. Part of me thinks that's a shame, because it seems like it's just that a for-profit entity behind the project was the only reason for doing so, but at the same time, the outcome isn't bad I think. Having multiple high-quality choices with different driving causes (and organizations) behind them is more beneficial in the long run than just one. Competition is good, even in open source, most the time.

light_hue_1 5y ago

This suggestion is a security nightmare! Anyone is one typo away from installing random junk from the internet on your machines. No one should be using docker in production while it can connect to a public registry where you have zero control of its contents.

infogulch 5y ago
Did you read my comment? Because I can't find any interpretation of your response that makes sense assuming you comprehend the actual content of my statements.
- light_hue_1 5y ago
  I did read the comment. And I comprehended the content of the statements. And I'm scared that this obvious security risk isn't horrifying to you. > I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conflated in various comments.) Use your own registry by specifying the domain first `myregistry.example.com/repo/image`; an unadorned `repo/image` being globally reserved as shorthand for `registry.docker.io/repo/image` seems fine. Allowing overriding the meaning of `repo/image` would be a support nightmare for both moby and internal IT, just use qualified names. Literally anyone in your company can forget to say `myregistry.example.com/` at any moment. And then your whole infrastructure runs on some random image that you didn't vet. You're a typo away from having your machines owned, your entire infrastructure falling over, your data being exposed to the anyone. This is no way to live and it's no way to run a company.

kbenson 5y ago

I believe that was acknowledged in some of the pull requests, and also a problem with correctly using credentials for repositories and various solutions were proposed (see one of my other comments for links). Ultimately, the reason given in the pull requests I saw was along the lines of "it will fracture the namespace and hurt the community". Disabling all registries except for those whitelisted and requiring full names for those would probably have been sufficient for this problem, and not fractured the community IMO. There's a difference between what you allow in dev and what you allow in production, where you should have a chance to vet all new requirements and ensure they are appropriate. It's just unacceptable for some organizations to allow stuff to be as ad hoc as that, as much as Docker might want to inject itself into their processes at that level.

infogulch 5y ago
> Disabling all registries except for those whitelisted and requiring full names for those would probably have been sufficient for this problem, and not fractured the community IMO. Yes this is what I was getting at. You don't need to override the meaning of image names, you just need to be able to disable registries outside your control and prefix all your images. It's like an additive vs subtractive blindness effect that caused people to miss this solution.
- kbenson 5y ago
  It wasn't missed, from what I saw in the issue and pull request. It was offered, and ignored. Part of me thinks that's a shame, because it seems like it's just that a for-profit entity behind the project was the only reason for doing so, but at the same time, the outcome isn't bad I think. Having multiple high-quality choices with different driving causes (and organizations) behind them is more beneficial in the long run than just one. Competition is good, even in open source, most the time.