Describe integer fields with JSON types and bound the descriptor size - #1334
Open
BobDu wants to merge 1 commit into
Open
Describe integer fields with JSON types and bound the descriptor size#1334BobDu wants to merge 1 commit into
BobDu wants to merge 1 commit into
Conversation
Signed-off-by: BobDu <i@bobdu.cc>
BobDu
requested review from
cyphar,
jonjohnsonjr,
sajayantony,
stevvooe,
sudo-bmitch and
tianon
as code owners
August 20, 2026 07:13
Member
|
Can you please elaborate succinctly on the specific problem you're trying to solve? I have read your description, but I don't really see a specific problem in it. |
This file contains hidden or 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
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.
#1249 made the I-JSON limitations of RFC 7493 a MUST for all JSON content in this specification, and RFC 7493 section 2.2 states that a sender cannot expect a receiver to treat an integer outside [-(2^53)+1, (2^53)-1] as an exact value. For the specification to be self-consistent the range permitted for
sizetherefore has to be a subset of that interval, and today it is not:defs-descriptor.jsonallows values up to 9223372036854776000.RFC 7493 attaches no requirement keyword to that interval; it only says that values outside it cannot be expected to be exact. Specifications built on I-JSON generally tighten it into a requirement so that values stay exact across implementations. RFC 8620 section 1.3 defines UnsignedInt as an integer where "the value MUST be in the range 0 <= value <= 2^53-1", and section 6.1 applies it to a directly comparable field: the size in octets of an immutable blob addressed by an id. RFC 9535 section 2.1 requires integers relevant to processing to be "within the range of exact integer values defined in Internet JSON (I-JSON) ..., namely within the interval [-(2^53)+1, (2^53)-1]".
This narrows the upper bound in theory, but it puts no valid existing data at risk: with the hardware available today an image cannot approach petabyte scale, and if that ever changes it will be a v2 concern.
Separately, this specification should be language neutral, and
int64is a Go type name. The specification only needs to state that the value is an integer and give its bounds; which data type an implementation uses is the implementation's choice and outside the scope of the specification.intis not a JSON type either, soschemaVersionin manifest.md and image-index.md is changed tointegerfor consistency.Changing the prose does not imply changing the Go types, which would be a breaking change. It only clarifies the specification document so that it is self-consistent and leaves no room for ambiguity, and it describes the current situation more closely, since oci-spec-rs defines the field as
u64.Related: #153, #350, https://github.com/youki-dev/oci-spec-rs/blob/42a237132bcaf7c6a753be0e1d7e309b7298fb5a/src/image/descriptor.rs#L40