Support shortname resolution for artifacts

[bitoku]

Pulling artifact doesn't support shortname resolution, which is supported for images.

❯ podman artifact pull crio/artifact:singlefile
Error: initializing source docker://crio/artifact:singlefile: reading manifest singlefile in docker.io/crio/artifact: requested access to the resource is denied

❯ podman pull crio/busybox
Trying to pull quay.io/crio/busybox:latest...
Getting image source signatures
Copying blob a3ed95caeb02 done
Copying blob f70adabe43c0 skipped: already exists
Writing manifest to image destination
8ac48589692a53a9b8c2d1ceaa6b402665aa7fe667ba51ccc03002300856d8c7

The registries.conf is

unqualified-search-registries = ["quay.io"]

The repository is available.
https://quay.io/organization/crio

version

❯ podman version
Client:       Podman Engine
Version:      5.7.0-dev
API Version:  5.7.0-dev
Go Version:   go1.25.3
Git Commit:   24872421a894f9ffde40fdc256c6886bc732b982
Built:        Mon Oct 20 16:18:46 2025
OS/Arch:      linux/amd64

container-libs version were:

	go.podman.io/common v0.65.1-0.20251016162239-c4c5e00ad22d
	go.podman.io/image/v5 v5.37.1-0.20251016133615-aa970d2c7532
	go.podman.io/storage v1.60.1-0.20251016133615-aa970d2c7532

Looking at the code, the image resolution code is implemented in common (code), so will the one for artifact be implemented in common?
Let me know if I should open an issue in c/podman repo.

[mtrmac]

Short names are generally a very bad idea, and IIRC it was an intentional decision not to repeat the mistake for artifacts. Cc: @Luap99 @baude .

[Luap99]

yeah I tend to agree we should not do shortnames but I am aware of explicit design discussions around it

[Luap99]

That said not doing shortnames also makes the UI much more confusing for users as some commands resolve the names and others not.

Also unqualified-search-registries and short name aliases are two different things, I assume we support neither? Should we support the short name aliases?

[mtrmac]

Aliases are primarily an interactive feature (with interactive prompts and users’ choices stored into per-user state); CRI-O can’t use that. Although it is possible to ship a set of pre-defined aliases in a system-wide config file ( https://github.com/containers/shortnames ) and IIRC OpenShift does ship some configuration of that kind.

Aliases are much better than search because they are not ambiguous, but there can still be conflicts (“to install our software, set the mysql alias to registry.vendor.example/our-patched-version/mysql” from two different vendors).

And, relevant for OpenShift, the only existing credential passing mechanism (to my knowledge) from users’ namespaces to CRI-O does not work with short names at all (compare the extremely horrible warning in https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/images/image-configuration-classic#images-configuration-shortname_image-configuration — basically any time the user references a short name, CRI-O receives, and will try to use, docker.io credentials with that short name). There were vague plans to fix that approximately forever, and it never happened — so I think adding any more short-name supporting features to Kubernetes is irresponsible.

If users want artifacts, it’s by definition a new application / deployment, so let them do the work to work with fully-qualified names only.

[bitoku]

Thank you for the explanation.
It makes sense that this is a design decision.

I also found that artifacts can't be specified by its digest if I pulled with a tag.

❯ podman artifact inspect quay.io/crio/artifact:singlefile
{
     "Manifest": {
          "schemaVersion": 2,
          "mediaType": "application/vnd.oci.image.manifest.v1+json",
          "artifactType": "application/x.test.test.test.v1",
          "config": {
               "mediaType": "application/vnd.oci.empty.v1+json",
               "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
               "size": 2,
               "data": "e30="
          },
          "layers": [
               {
                    "mediaType": "application/vnd.oci.image.layer.v1.tar",
                    "digest": "sha256:d1cc3064379fca32757730461bd728cb7de430e46a0046aa59ab55c65be7ce3b",
                    "size": 14,
                    "annotations": {
                         "org.opencontainers.image.title": "artifact.txt"
                    }
               }
          ],
          "annotations": {
               "org.opencontainers.image.created": "2025-03-13T00:12:12Z"
          }
     },
     "Name": "quay.io/crio/artifact:singlefile",
     "Digest": "sha256:d2dbbc46e94529be98d2513fe2a46ef650683af96c584e1287dd966300aaf583"
}

❯ podman artifact inspect quay.io/crio/artifact@sha256:d2dbbc46e94529be98d2513fe2a46ef650683af96c584e1287dd966300aaf583
Error: quay.io/crio/artifact@sha256:d2dbbc46e94529be98d2513fe2a46ef650683af96c584e1287dd966300aaf583: artifact does not exist

Also latest tag is not automatically appended to the artifact name.

❯ podman artifact inspect quay.io/crio/busybox
Error: quay.io/crio/busybox: artifact does not exist

❯ podman artifact inspect quay.io/crio/busybox:latest
{
     "Manifest": {
          "schemaVersion": 2,
          "mediaType": "application/vnd.oci.image.manifest.v1+json",
          "config": {
               "mediaType": "application/vnd.oci.image.config.v1+json",
               "digest": "sha256:eb13477d9ef899224bc2dea9698a335e9cf9df1a8d284a26a0c8797444a74202",
               "size": 594
          },
          "layers": [
               {
                    "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
                    "digest": "sha256:f70adabe43c0cccffbae8785406d490e26855b8748fc982d14bc2b20c778b929",
                    "size": 723172
               }
          ]
     },
     "Name": "quay.io/crio/busybox:latest",
     "Digest": "sha256:f2463a82068a315d4661261907dcc33b6daac88ec2082eddb755bd061660f9ae"
}

Those behaviors are also different from images. Are they also intentional?
If I should open a new issue for it, feel free to close this issue and I'll open a new one.

[Luap99]

latest tag is tacked in containers/podman#27083

The digest likely deserve its own bug, that should work I assume

[bitoku]

Thanks I opened #408 and closing this one.

[bitoku]

Sorry, let me reopen this issue, because I have something I want to confirm.

This command successfully pulled nginx image. I don't set no nginx aliases in the config.
Is this, resolving to docker.io by default, intentional as well?

❯ podman artifact pull nginx
Getting image source signatures
Copying blob 80bfbb8a41a2 done   |
Copying config 0ed463b26d done   |
Writing manifest to image destination

According to the log, it seems it uses docker.io/library/nginx.

DEBU[0000] Trying to access "docker.io/library/nginx:latest"

Apparently, any images are resolved to docker.io/library/<name>.

❯ podman artifact pull aaaaaaaa
Error: initializing source docker://aaaaaaaa:latest: reading manifest latest in docker.io/library/aaaaaaaa: requested access to the resource is denied

also this artifact can be specified only with nginx not docker.io/library/nginx.

❯ podman artifact inspect nginx
{
...
}

❯ podman artifact inspect docker.io/library/nginx
Error: docker.io/library/nginx: artifact does not exist

[mtrmac]

Hum… with my c/image hat on, I’m fine with short names always, deterministically, resolving to docker.io[/library]. There is no ambiguity.

As for whether c/common or Podman should enforce users writing a fully-qualified name and avoid this special case, I don’t have a strong opinion.

But what is the CRI-O impact? The “image volume” pulls happen through the long-standing CRI-O “PullImage” API, don’t they? In that case Kubelet ~correctly finds the docker.io credentials, and correctly passes them to CRI-O, so that works — but CRI-O’s PullImage is implemented to interpret short names as a search, consuming the credentials incorrectly again. And only within the short-name-search loop it finds that the input might be an artifact and switches to an artifact-pulling backend.

So, for CRI-O, I think it’s still desirable to prohibit short names, and that implies that they should be prohibited for Podman, and in the c/common shared code, as well. @containers/podman-maintainers ?

[Luap99]

I was talking with @baude today, I think the consensus is do not allow any short names whatsoever so we should enforce that.

[baude]

Correct, shortnames should not be used. We can enforce that reasonably simply.

After talking with @mtrmac , I will make a proposal for a new type of ArtifactReference which would contain something like a namedD. Then we'd have a New constructor that would do all the validation of "rules" and return an error on the invalid reference. This would become a type change, however, so would everyone be cool with that ?

@Luap99 @mtrmac @rhatdan @bitoku