5 ms·

Personally - I don't really see this one making sense. There's already a widely available way to specify exactly which repo you'd prefer in the docker client..

Personally - I don't really see this one making sense. There's already a widely available way to specify exactly which repo you'd prefer in the docker client... `docker pull [repo]/[image]:[tag]` And that address format works across basically all of the tooling. Changing the defaults doesn't actually make sense, because there's no guarantee that repo1/secure_image === repo2/secure_image. Seems like a HUGE security issue to default named public images to a repo where the images may not be provided by the same owner.

lolinder 2y ago
I like Podman's solution: all images must be fully qualified, with even Docker Hub images requiring a docker.io/ prefix.
- raesene9 2y ago
  Fully qualified is indeed the way to go. Unfortunately a lot of tutorials manifests and other materials have short names, and changing the default registry just opens up a load of typo squatting attacks.
- ffsm8 2y ago
  That's a very good argument, but people have down used to dropping the domain prefix because it's always been optional. Giving people the option to configure a default repository via the daemon.json would alleviate that issue, but I'm not sure if that's really enough to fork.
  - hedora 2y ago
    They’ve been betting it’s not for about ten years. With these changes, I can imagine “intro to docker” tutorials breaking. I suspect that’ll be enough to let a fork/competitor gain significant market share.
    - theamk 2y ago
      hm.. switch to fork just to avoid trivial, mechanical, 10-character change in docs and scripts? (image/name -> my-repo.com/image/name) I doubt it.
      - DangitBobby 2y ago
        The web is absolutely littered with docker tutorials and a huge proportion of them (not operated or maintained by docker themselves) would no longer be valid, I'm sure.
  - jjfanboy 2y ago
    Oh great, so now it's a hidden default that might be different system-to-system. Disjoint from the actual deployment config. Please, dear god, no. I'm sorry, this is a bad idea. It's just not that hard to go fully qualified.
    - sodality2 2y ago
      If you specify the fully qualified image location then it's irrelevant. It's only when you decide to use short hand that it comes into concern
- bArray 2y ago
  I agree it's the better proposal, but it does slightly break the "drop-in"-ness of Podman.
  - jchw 2y ago
    When using Podman as an alias for Docker, it does automatically resolve from Dockerhub when not specified. This is configurable, though.
- Arnavion 2y ago
  That said, they also maintain a list of aliases for a bunch of container images. https://github.com/containers/shortnames https://github.com/containers/shortnames . My distro's podman package then drops in that file into /etc/containers/registries.conf.d/ via one of the package's dependencies.
OptionOfT 2y ago
That's why it is imperative that you use sha256 digests. Remember, tags are mutable. `latest` today can be different tomorrow. And it expands to all other tags. Nothing prevents me from pushing a new 'version' of a container to an existing `v1.0.1` tag. Tags are not a way of uniquely identifying a container.
- londons_explore 2y ago
  that really depends on your thoughts of the trustworthiness of the 'owners' of those tags vs the security bugs in the sha256 you pinned and then didn't keep an eye on...
- horsawlarway 2y ago
  Sure, digests are a good tool when needed, but there's a huge gulf between the risk factors here, and they don't really solve the "trust across repos" problem. The top level image hashes tend to change between repos (because the image name changes in the manifest and is included in the hash). So you'd have to go through an verify each layer sha. Good tool for selecting an exact image in a repo, not a replacement for trust at the naming level (it's a bit like the difference between owning a domain and cert pinning with hpkp).
  - cpuguy83 2y ago
    Who's adding image name (with or even without repo name) to the manifest? That's just a terrible idea.
    - horsawlarway 2y ago
      Manifests are tacked on afterwards, and have a lot of complexity that I'm not sure most folks have actually thought through. Ex - lots of refs are to "multi-arch" images, Except... there's no such thing as a multi-arch image, the entire identifier is just a reference to a manifest that then points to a list of images (or other manifests) by arch, and the actual resolved artifact is a single entry in that list. But it means the manifest needs to be able to reference and resolve other names, and that means including... names. For a more concrete example, just check https://github.com/moby/moby/issues/44144#issuecomment-1257873446 https://github.com/moby/moby/issues/44144#issuecomment-12578... Basically - the digests weren't intended to support image verification across repos, and the tool doesn't treat them that way. The digest was intended to allow tighter specification than a tag (precisely because a publisher might push a different image to the same tag later).

lolinder 2y ago

I like Podman's solution: all images must be fully qualified, with even Docker Hub images requiring a docker.io/ prefix.

raesene9 2y ago
Fully qualified is indeed the way to go. Unfortunately a lot of tutorials manifests and other materials have short names, and changing the default registry just opens up a load of typo squatting attacks.
ffsm8 2y ago
That's a very good argument, but people have down used to dropping the domain prefix because it's always been optional. Giving people the option to configure a default repository via the daemon.json would alleviate that issue, but I'm not sure if that's really enough to fork.
- hedora 2y ago
  They’ve been betting it’s not for about ten years. With these changes, I can imagine “intro to docker” tutorials breaking. I suspect that’ll be enough to let a fork/competitor gain significant market share.
  - theamk 2y ago
    hm.. switch to fork just to avoid trivial, mechanical, 10-character change in docs and scripts? (image/name -> my-repo.com/image/name) I doubt it.
    - DangitBobby 2y ago
      The web is absolutely littered with docker tutorials and a huge proportion of them (not operated or maintained by docker themselves) would no longer be valid, I'm sure.
- jjfanboy 2y ago
  Oh great, so now it's a hidden default that might be different system-to-system. Disjoint from the actual deployment config. Please, dear god, no. I'm sorry, this is a bad idea. It's just not that hard to go fully qualified.
  - sodality2 2y ago
    If you specify the fully qualified image location then it's irrelevant. It's only when you decide to use short hand that it comes into concern
bArray 2y ago
I agree it's the better proposal, but it does slightly break the "drop-in"-ness of Podman.
- jchw 2y ago
  When using Podman as an alias for Docker, it does automatically resolve from Dockerhub when not specified. This is configurable, though.
Arnavion 2y ago
That said, they also maintain a list of aliases for a bunch of container images. https://github.com/containers/shortnames https://github.com/containers/shortnames . My distro's podman package then drops in that file into /etc/containers/registries.conf.d/ via one of the package's dependencies.

OptionOfT 2y ago

That's why it is imperative that you use sha256 digests. Remember, tags are mutable. `latest` today can be different tomorrow. And it expands to all other tags. Nothing prevents me from pushing a new 'version' of a container to an existing `v1.0.1` tag. Tags are not a way of uniquely identifying a container.

londons_explore 2y ago
that really depends on your thoughts of the trustworthiness of the 'owners' of those tags vs the security bugs in the sha256 you pinned and then didn't keep an eye on...
horsawlarway 2y ago
Sure, digests are a good tool when needed, but there's a huge gulf between the risk factors here, and they don't really solve the "trust across repos" problem. The top level image hashes tend to change between repos (because the image name changes in the manifest and is included in the hash). So you'd have to go through an verify each layer sha. Good tool for selecting an exact image in a repo, not a replacement for trust at the naming level (it's a bit like the difference between owning a domain and cert pinning with hpkp).
- cpuguy83 2y ago
  Who's adding image name (with or even without repo name) to the manifest? That's just a terrible idea.
  - horsawlarway 2y ago
    Manifests are tacked on afterwards, and have a lot of complexity that I'm not sure most folks have actually thought through. Ex - lots of refs are to "multi-arch" images, Except... there's no such thing as a multi-arch image, the entire identifier is just a reference to a manifest that then points to a list of images (or other manifests) by arch, and the actual resolved artifact is a single entry in that list. But it means the manifest needs to be able to reference and resolve other names, and that means including... names. For a more concrete example, just check https://github.com/moby/moby/issues/44144#issuecomment-1257873446 https://github.com/moby/moby/issues/44144#issuecomment-12578... Basically - the digests weren't intended to support image verification across repos, and the tool doesn't treat them that way. The digest was intended to allow tighter specification than a tag (precisely because a publisher might push a different image to the same tag later).