Incorrect OCI Mediatype after copy from containers-storage

[besnardjb]

Dear maintainers,

tl;dr:
I end up with an incorrect OCI mediaType in the final image ("application/vnd.oci.image.layer.v1.tar" instead of "application/vnd.oci.image.layer.v1.tar+gzip").

I would like to report an oddity I've encountered while using skopeo in conjunction with buildah. Given my limited knowledge of the codebase, it appeared to me that the issue was related to the skopeo copy operation, I hope that it is correct.

This is how I encounter the issue:

buildah @ containers/buildah@08c5630
skopeo @ 82186b9

# cat ~/Dockerfile 
from alpine
run apk update
run apk add vim
# buildah bud -t myalpine ~
(...)
# skopeo copy containers-storage:localhost/myalpine oci:myalpine-oci
(...)
# cat myalpine-oci/blobs/sha256/7f1e9b82c40554ac10736301440c3c039cea2c75d701b05a4042e622c672a0ff | jq 
{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:0d67e56c33b13724414ebcacd937defd6d3554af21aa565865e525e90b6310b4",
    "size": 721
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:8e3ba11ec2a2b39ab372c60c16b421536e50e5ce64a0bc81765c2e38381bcff6",
      "size": 2206542
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:73227f01ebef2b94007ae82318337546720979eaee2871648e7cf147c7b8cad8",
      "size": 10358984
    }
  ]
}
# file myalpine-oci/blobs/sha256/8e3ba11ec2a2b39ab372c60c16b421536e50e5ce64a0bc81765c2e38381bcff6
myalpine-oci/blobs/sha256/8e3ba11ec2a2b39ab372c60c16b421536e50e5ce64a0bc81765c2e38381bcff6: gzip compressed data

We can see that blob 8e3ba11ec2a2b39ab372c60c16b421536e50e5ce64a0bc81765c2e38381bcff6 is tagged "application/vnd.oci.image.layer.v1.tar" but practically gzipped. This may confuse a bundle extractor trusting OCI layer meta-data (e.g. umoci here https://github.com/openSUSE/umoci/blob/86a1af2e89e98bfc2327ac3d0655ab4b30554cc2/oci/layer/unpack.go#L88).

From my (limited) understanding, it seems that the resulting layer type was set when pulling the image outside of the containers-storage in the following file containers/storage/storage_image.go:192 through the following line :

uncompressedLayerType = imgspecv1.MediaTypeImageLayer

It seems that it was not set back to MediaTypeImageLayerGzip afterwards.

Thanks!

[mtrmac]

Thanks for the report.

Yes, this is a known bug: copy.Image, in copyBlobFromStream, can compress/decompress layers, but does not adjust MIME types.

[rhatdan]

@mtrmac @vrothberg Is this something we are going to fix?

[mtrmac]

Hopefully.

[mtrmac]

This might have been fixed by containers/image#563 .

[besnardjb]

I confirm this problem is fixed in current master @ f72e39f.

I repeated the steps of my small reproducer, with a previously installed version version 0.1.36-dev commit: 854f766:

    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:519cb705bc6d8fc480c8ca57488bcc9f588997e3030978ba4b8b47030831aa67",
      "size": 2861852
    },

$ file blobs/sha256/519cb705bc6d8fc480c8ca57488bcc9f588997e3030978ba4b8b47030831aa67
blobs/sha256/519cb705bc6d8fc480c8ca57488bcc9f588997e3030978ba4b8b47030831aa67: gzip compressed data

And now with version 0.1.40-dev commit: f72e39f

    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:519cb705bc6d8fc480c8ca57488bcc9f588997e3030978ba4b8b47030831aa67",
      "size": 2861852
    },

Thanks !

[vrothberg]

Thanks for reporting and checking, @besnardjb!