Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing support for zstd compressed images #95

Closed
k-gostev opened this issue Oct 7, 2022 · 4 comments
Closed

Missing support for zstd compressed images #95

k-gostev opened this issue Oct 7, 2022 · 4 comments

Comments

@k-gostev
Copy link

k-gostev commented Oct 7, 2022

Issue Description:

It seems that working with an image that have a layer with media type application/vnd.oci.image.layer.v1.tar+zstd is not possible. When I try to encrypt or even use layerinfo I see that the following error is returned:

ctr: unhandled media type application/vnd.oci.image.layer.v1.tar+zstd: invalid argument

Also $ ctr-enc containers create repo:port/zstd-image:latest some-id fails with:

ctr: you are not authorized to use this image: bad/unhandled MediaType application/vnd.oci.image.layer.v1.tar+zstd in encryptChildren

The zstd compression format is supported by containerd and for example $ ctr containers create repo:port/zstd-image:latest hello-world-zstd is working as expected and the desired container is created successfully.

Steps to reproduce:

To reproduce the issue one can use skopeo to change the compression of a simple hello-world image and then push it to a private/local registry, e.g.:

  1. Use skopeo copy to create a zstd-compressed image and push it locally:
$ skopeo copy --dest-compress-format=zstd docker://hello-world docker://<some-plain-http-local-ip:port>/hello-world-zstd:latest --dest-tls-verify=false
  1. Use skopeo inspect to check the result pushed image compression:
$ skopeo inspect --raw docker://<some-plain-http-local-ip:port>/hello-world-zstd:latest --tls-verify=false | jq -r '.layers[].mediaType'
  1. Pull the image:
$ ctr-enc image pull --plain-http <some-plain-http-local-ip:port>/hello-world-zstd:latest
  1. Try any of the following commands:
$ ctr-enc image encrypt <some-plain-http-local-ip:port>/hello-world-zstd:latest --recipient=pgp:[email protected]
$ ctr-enc containers create <some-plain-http-local-ip:port>/zstd-image:latest some-id

Proposal:

In my opinion the compression part of the media type should not be taken into account as (please correct me if I am wrong) it is not relevant to the encryption process. So, the checks that are done here, here and probably in some other parts of the code that I haven't explore, could be refactored in a way that disregards the compression type, whether it is zstd or something else.
As a proof of my thoughts I have done locally the most simple test, which is just adding application/vnd.oci.image.layer.v1.tar+zstd and application/vnd.oci.image.layer.v1.tar+zstd+encrypted to the switch/case blocks in the functions linked above and as expected the encryption and creation of the container was successful. So, I think that it would be nice to have more flexibility regarding the verification of media types that are supported by the library.

@stefanberger
Copy link
Contributor

Thanks for reporting this. Do you have a patch I can just apply with the zstd changes or can you send PR ?

@stefanberger
Copy link
Contributor

I sent this PR now to ocircyrpt: containers/ocicrypt#68

stefanberger added a commit to stefanberger/imgcrypt that referenced this issue Oct 7, 2022
@k-gostev
Copy link
Author

k-gostev commented Oct 7, 2022

Thanks @stefanberger! I will prepare a PR for this issue.

stefanberger added a commit to stefanberger/imgcrypt that referenced this issue Oct 7, 2022
@stefanberger
Copy link
Contributor

Add a PR now that should resolve the issue.

stefanberger added a commit to stefanberger/imgcrypt that referenced this issue Oct 7, 2022
stefanberger added a commit to stefanberger/imgcrypt that referenced this issue Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants