containers / skopeo

Work with remote images registries - retrieving information, images, signing content
Apache License 2.0
7.75k stars 756 forks source link

`skopeo inspect tarball:` returns MIMEType as OCI Image spec only #2338

Closed tnk4on closed 3 days ago

tnk4on commented 1 month ago

If I run skopeo inspect tarball: on a Docker V 2, Schema 2 (docker-archive) image saved with podman save or docker save, the response is an OCI Image.

$ podman pull docker.io/library/alpine
$ podman save -o alpine-docker.tar --format docker-archive alpine
$ podman save --format docker-archive alpine | gzip > alpine-docker.tar.gzip
$ podman save -o alpine-oci.tar --format oci-archive alpine
$ podman save --format oci-archive alpine | gzip > alpine-oci.tar.gzip
$ ls -l
total 20912
-rw-r--r--. 1 core core 9120256 May 24 17:47 alpine-docker.tar
-rw-r--r--. 1 core core 3958359 May 24 17:47 alpine-docker.tar.gzip
-rw-r--r--. 1 core core 4205568 May 24 17:48 alpine-oci.tar
-rw-r--r--. 1 core core 4122277 May 24 17:49 alpine-oci.tar.gzip
$ skopeo inspect tarball:alpine-docker.tar --format '{{(index .LayersData 0).MIMEType}}'
application/vnd.oci.image.layer.v1.tar
$ skopeo inspect tarball:alpine-docker.tar.gzip --format '{{(index .LayersData 0).MIMEType}}'
application/vnd.oci.image.layer.v1.tar+gzip
$ skopeo inspect tarball:alpine-oci.tar --format '{{(index .LayersData 0).MIMEType}}'
application/vnd.oci.image.layer.v1.tar
$ skopeo inspect tarball:alpine-oci.tar.gzip --format '{{(index .LayersData 0).MIMEType}}'
application/vnd.oci.image.layer.v1.tar+gzip

Is it possible to fix it to respond with Docker V2S2?

tnk4on commented 1 month ago

The c/image source code is hard coded to OCI Image and there is no logic to determine Docker V2S2. https://github.com/containers/image/blob/a6fbeaa1800f1081033a28771626e48d9042a99d/tarball/tarball_src.go#L85-L103

mtrmac commented 1 month ago

Thanks for reaching out. tarball is an internal implementation mechanism of some features, and basically completely impossible to use from the command line.

To consume files created by podman save, use a specific transport relevant to the image format, in this case docker-archive: or oci-archive:

Also consider restructuring your workflow to use a registry, it’s almost certainly going to be more efficient than using tarballs because it allows sharing layer data across images and repositories, and it does not require creating temporary files to consume compressed data.

tnk4on commented 1 month ago

My goal is to easily know the format of archives saved by podman save or docker save. I need to run two commands skopeo inspect oci-archive: and skopeo inspect docker-archive: for archives of unknown format. What about the idea of adding the ability to fall back to the proper format?

mtrmac commented 1 month ago

That’s fundamentally ambiguous — a tarball can be purposely built to be valid in several formats simultaneously, and to contain a different image in each. Autodetection would increase user risk if consuming third-party tarballs.

I think it would make more sense to follow what Docker does (as in https://github.com/containers/podman/issues/21347 ), and to intentionally generate such ambiguous OCI-compatible archives with --format=docker. Then users of skopeo inspect could always, consistently use oci-archive: and wouldn’t need to worry about auto detection.

tnk4on commented 1 month ago

I understand about the ambiguity of tarballs. thank you ! So how about adding the information to the output of the tarball transport? e.g. “The MIMEType output may differ from the actual format. Please use oci-archive: or docker-archive: transport instead.”

mtrmac commented 1 month ago

The tarball: transport is completely out of the picture. It’s just not its purpose at all to consume podman save.

tnk4on commented 1 month ago

Just like I did, people who are not familiar with using skopeo might expect the tool to be perfect. It would be helpful to supplement this with documentation.

mtrmac commented 1 month ago

That’s very true. How did you find the tarball: transport at all? It is explicitly missing from containers-transports(5), and I can’t see it being documented anywhere, other than a brief mention in containers-policy.json(5).

If it is documented somewhere else, we should fix that.

tnk4on commented 1 month ago

I found it in bash-completion while testing the command and tried it. I have not looked for any other documentation other than that.

mtrmac commented 1 month ago

Thanks, #2339 will filter it out.

github-actions[bot] commented 4 days ago

A friendly reminder that this issue had no activity for 30 days.