-
Notifications
You must be signed in to change notification settings - Fork 379
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
zstd:chunked and layer encryption don’t make sense together #2485
Comments
yes, I agree we cannot use partial pulls with encryption for now and it will be better to reject such combination. |
One more aspect: This also breaks the “convert non-chunked images to chunked [in order to use composefs]” path for encrypted images, because it is built around |
#2321 now includes logic to use zstd instead of zstd:chunked when encrypting (or to fail if the configuration is to use exactly the requested algorithm). |
c/image now throws a warning when using encryption and zstd:chunked as they do not work together[1]. As CI uses default configs from fedora it means rawhide now defaults to zstd:chunked which trigger the warning there. To work around that force zstd compression. [1] containers/image#2485 Signed-off-by: Paul Holzinger <[email protected]>
Add a fix to pull to address a zstd:chunked issue as noted in containers/image#2485 Signed-off-by: tomsweeneyredhat <[email protected]>
Add a fix to pull and push tests to address a zstd:chunked issue as noted in containers/image#2485 Signed-off-by: tomsweeneyredhat <[email protected]>
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
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.
The text was updated successfully, but these errors were encountered: