skopeo inspect tarball: returns MIMEType as OCI Image spec only

[tnk4on]

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]

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]

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]

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]

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 containers/podman#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]

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]

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

[tnk4on]

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]

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]

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]

Thanks, #2339 will filter it out.

[github-actions]

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