issues about copy with encryption/decryption for docker image format about image

[mtrmac]

Thanks for your report.

For clarity, it would be useful to collect specific reproducers.

Here’s what I think you are reporting; please correct me if that’s not the case.

during the copy encryption process, when the format of the source image is Docker image format and the format of the target image is Docker image format, although the conversion is successful, the ocicrypt encryption operation is not actually performed on the blob, which will cause data to be encrypted is not protected by encryption.

That’s not what I see:

% skopeo --override-os linux --insecure-policy copy --format v2s2 --debug docker://quay.io/libpod/alpine:3.10.2 dir:clear1

Then

% skopeo --override-os linux --insecure-policy copy --encryption-key jwe:./public.key  --debug dir:clear1 dir:enc1 
…DEBU[0000] Manifest has MIME type application/vnd.docker.distribution.manifest.v2+json, ordered candidate list [] 
FATA[0000] Internal error: no candidate MIME types      

so that operation is correctly rejected, although in an unclean way.

Bug A: This should report correct user-facing failure instead of “internal error”.

---

Only when explicitly forcing the copy to go through:

% bin/skopeo --override-os linux --insecure-policy copy --encryption-key jwe:./public.key --format v2s2  --debug dir:clear1 dir:enc1

the copy succeeds, but it does encrypt the data:

% file clear1/* enc1/*
…
clear1/9d16cba9fb961d1aafec9542f2bf7cb64acfc55245f9e4eb5abecd4cdc38d749: gzip compressed data, original size modulo 2^32 5843968
…
enc1/fc551411212b599459b1885694e518bdf0b01df28acca35f868b0460634ad440:   data
…

so at least it is not exposed unexpectedly (but it is also not consumable, because the metadata is missing)

Bug B: An explicit copy.Options.ForceManifestMIMEType choice which does not support encryption is not rejected.

---

When encrypting an OCI image into another image format expect OCIv1, although the blob will be encrypted, the target image format does not support encryption, so the metadata will not be marked with an encryption flag, which will cause the user who uses the image to not know the image has been encrypted

Testing this:

% skopeo --override-os linux --insecure-policy copy --format oci --debug docker://quay.io/libpod/alpine:3.10.2 dir:clear2         
% skopeo --override-os linux --insecure-policy copy --encryption-key jwe:./public.key  --debug dir:clear2 docker-archive:/dev/null

(using docker-archive to trigger a Docker conversion without explicit --format, which we know is buggy per Bug B), this does actually succeed.

Bug C: A copy to a transport that triggers a conversion to a format does not support encryption is not rejected. (This is actually the same thing as Bug B, internally, but let’s track it separately.)

---

If the user tries to encrypt and decrypt between non-OCI images, it should fail

Why so general? In principle, I’d expect encryption of a non-OCI image to be possible, and decryption to a non-OCI format to be possible. Some of that might not (yet) be implemented.

if the user tries to decrypt an OCI encrypted image to a non-OCI image format, it should fail

Why?

if the user tries to encrypt a non-OCI image into an OCI encrypted image, it should fail, because this triggers the former case to happen.

I don’t see how that relates. If the encryption correctly creates a correct encrypted image, bugs in consumers (even if the consumer is the same software) are a separate issue.

---

Propose 2: Add MediaTypeImageLayerEncrypt= "application/vnd.oci.image.layer.v1.tar+encrypted" to the convertToManifestSchema2 of internal/image/oci.go to take application/vnd.oci.image.layer.v1.tar+encrypted as application/vnd.oci.image.layer.v1.tar to trigger manifest conversion and use original blob without modification.\

I’m not sure I understand what you are proposing. Are you saying that conversion to schema2 should keep the encrypted layer in the encrypted format? That just wouldn’t work because schema2 can’t carry the annotations required to decrypt.

[mtrmac]

Bug A: This should report correct user-facing failure instead of “internal error”.

Actually, a copy to dir: should trigger a conversion, and succeed.

[mtrmac]

#1930 should fix the identified bugs. I’d appreciate testing and any other feedback.