zstd:chunked is built around the idea that we can independently read individual parts of the layer via range requests.

That’s not directly possible when the layer is encrypted (when the encryption is a completely abstract stream transformation). So we see chunked pull failures like

DEBU[0000] GET http://localhost:50000/v2/encrypted/blobs/sha256:… 
DEBU[0000] Failed to retrieve partial blob: read zstd:chunked manifest: validating and decompressing TOC: invalid blob checksum, expected checksum sha256:…, got sha256:… 

That doesn’t really hurt because we then fall back to the non-chunked pull path, still at least the effort during a push is a waste. (Also, the annotations are unencrypted and leak a bit of information about layer contents — probably not more than the unencrypted config, but, still.)

It might be possible to implement this if the encryption format committed to being seekable/restartable (and many of cipher modes can be used that way, at least as long as they are not AEAD). OTOH that would require plumbing encryption directly through the GetBlobAt call stack, a fair bit of complexity, in addition to having ocicrypt choose the right algorithms and provide APIs to support seekable encryption.

Short-term, I think it makes most sense to just refuse to do this; if the user asks for zstd:chunked encryption, we should automatically (with a warning?) downgrade to non-chunked zstd output. Maybe, if the user explicitly asks for chunked on the CLI (as opposed to the config file), we should outright fail.

Cc: @giuseppe @rhatdan — this seems to be a fairly obvious decision, at least for now, but there might be use cases I don’t know about.