Respect registries.conf search list for image pulls

[adambkaplan]

buildah pull currently does not consult the registries.conf search list when doing an image pull. It instead uses "docker-centric" logic to pull from docker.io if no repository is specified in an image pull spec.

This can cause builds to break if docker.io is not in the registries.conf search path. See report in containers/image#572.

[rhatdan]

Tom can you check this and make it work the same way podman pull works?

@vrothberg @mtrmac Is this something that is being moved into container/image?

[mtrmac]

c/image won’t natively implement the signature-breaking search in the docker:// transport if I can help it. We have been speculatively talking about sharing the buildah and Podman implementations, maybe placing that shared code in some explicitly-opt-in subpackage of c/image (better to have one problematic code than two), but for now the two are different (and a bit diverging over time).

FWIW I’ve managed to convince OpenShift to give up on search ( openshift/builder#40 openshift/api#192 ) as it has never worked as expected with authentication, so I’m not sure how urgent this is for buildah.

Still, it’s very reasonable to expect that buildah from, FROM in buildah bud, and buildah pull all behave the same.

[vrothberg]

FWIW I’ve managed to convince OpenShift to give up on search ( openshift/builder#40 openshift/api#192 ) as it has never worked as expected with authentication, so I’m not sure how urgent this is for buildah.

Thanks so much 🙏 I would very much like to deprecate the search registries as they actually serve as mirrorr/pull endpoints for docker.io. Expanding an unqualified image (e.g., alpine:latest to docker.io/library/alpine:latest) is an implementation detail of Docker but not defined in any spec. Adding mirrors to docker.io would make this fact a bit clear IMHO.

[mtrmac]

Thanks so much 🙏 I would very much like to deprecate the search registries as they actually serve as mirrorr/pull endpoints for docker.io.

That’s not quite how we think of them; projectatomic/docker has diverged from upstream (e.g. in projectatomic/docker@8193836 ) to define (hostname-)“qualified”/“unqualified” names; unqualified mean “use the search list”, but that’s not the same thing as treating the search list as mirrors — notably

1. the pulled image is tagged with the hostname found during the search, not as docker.io
2. the pull uses credentials for that hostname, not for docker.io.

Expanding an unqualified image (e.g., alpine:latest to docker.io/library/alpine:latest) is an implementation detail of Docker but not defined in any spec.

Right, there is a spec for how to pull from a registry, but not for what the docker CLI arguments mean. The --add-registry patch has redefined that… and succeeded enough that we probably can’t just drop the shorthand search notation, I’m afraid.

Ideally, I’d like to have aliases instead of search (pull $fedora, with a config file defining $fedora = registry.fedoraproject.org/…).

[rhatdan]

This is fixed in master branch.