fix: drop embedded config data from manifest image #774
+2
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The [OCI spec](https://github.com/opencontainers/image-spec/blob/main/descriptor.md#properties) provides a `data` field in order to embed a copy of an image's config directly into that image's manifest: > data string > > This OPTIONAL property contains an embedded representation of the referenced content. Values MUST conform to the Base 64 encoding, as defined in RFC 4648. The decoded data MUST be identical to the referenced content and SHOULD be verified against the digest and size fields by content consumers. See Embedded Content for when this is appropriate. This is [intended as an optimization](https://github.com/opencontainers/image-spec/blob/main/descriptor.md#embedded-content), in order to reduce the number of network round-trips incurred to pull a container from a remote repository. However, as highlighted in the release announcement for the new [`data` field](https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/#data-field), the contexts in which an embedded config is beneficial can be a subtle determination. Further, in the same announcement, the spec clarified that registry implementations usually enforce a [maximum size](https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/#manifest-maximum-size) on manifests, an obscure limit which incautious use of the `data` field can trigger. Given the trade-offs dropping any embedded data (e.g. that might have been propagated from a base image) seems the preferable option. The alternative — updating embedded data to match the config on every change, as proposed by bazel-contrib#757 — is less universally correct and only sometimes more performant. Either option would satisfy bazel-contrib#756 .
thesayyn
reviewed
Feb 11, 2025
plobsing
changed the title
thesayyn
approved these changes
Feb 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The OCI spec provides a
datafield in order to embed a copy of an image's config directly into that image's manifest:This is intended as an optimization, in order to reduce the number of network round-trips incurred to pull a container from a remote repository.
However, as highlighted in the release announcement for the new
datafield, the contexts in which an embedded config is beneficial can be a subtle determination. Further, in the same announcement, the spec clarified that registry implementations usually enforce a maximum size on manifests, an obscure limit which incautious use of thedatafield can trigger.Given the trade-offs, dropping any embedded data (e.g. that might have been propagated from a base image) seems the preferable option. The alternative — updating embedded data to match the config on every change, as proposed by #757 — is less universally correct and only sometimes more performant. Either option would fix #756 .