Improve errors reported when pulling encrypted images without decryption #2646
Labels
kind/feature
A request for, or a PR adding, new functionality
Comments
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Nov 28, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Nov 28, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Nov 28, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Nov 29, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Nov 29, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Nov 29, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Dec 12, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
mtrmac
added a commit
to mtrmac/libpod
that referenced
this issue
Dec 14, 2024
containers/image#2646 will track actually returning a meaningful error instead of these internal details. Signed-off-by: Miloslav Trmač <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, pulls of encrypted layers try to decrypt and extract them without handing encrypted data specially, so, we see something including
invalid tar header(or, with future #2613,writing blob: layer 0 (blob "sha256:…"/""/"sha256:…") does not match config's DiffID "sha256:…").That’s valuable for tests because we can ensure that the data really is encrypted, but bad for users.
We should add a “requires decrypted layers” field to
private.ImageDestination, and abort a copy before starting to read any layers ifisEncryptedand the transport requires decryption.The text was updated successfully, but these errors were encountered: