From the referenced OCI spec:
digest ::= algorithm ":" encoded
algorithm ::= algorithm-component (algorithm-separator algorithm-component)*
algorithm-component ::= [a-z0-9]+
algorithm-separator ::= [+._-]
encoded ::= [a-zA-Z0-9=_-]+
But from the distribution-spec:
Throughout this document, `<reference>` as a tag MUST be at most 128 characters in length and MUST match the following regular expression:
`[a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}`
Happily, the fist character of algorithm must match
algorithm-component, and its [a-z0-9] a subset of the tag regexp's
opening [a-zA-Z0-9_]. And the colon separating algorithm from encoded
was already addressed in the outgoing text. But the digest definition
also allows + in the algorithm-separator and = in the encoded portion,
which the tag regexp does not allow, so with the incoming wording I'm
requiring that to be replaced by a - as well, so clients make
consistent choices when deciding how to handle that character while
forming distribution-spec referrer tags.
We need some overall truncation to keep the tag under 128 characters,
again so clients make consistent choices when trying to compress from
the strings the digest specification allows to the strings tags allow.
There is no requirement in the distribution spec as far as I can tell
that registries support tags up to 128 characters, but given that the
spec explicitly requires clients to not exceed that length, it seems
likely that registries will allow tags of that length, and not require
further truncation.
I'm requiring clients to truncate the algothim to 32 characters and
the encoded section to 64 characters, because that's one possible
reading of the outgoing "limit of 64 characters" parenthetical, at
least one client had implemented it that way [1], and Brandon
explicitly requested the 32-and-64 approach [2].
And clients are obviously free to create whatever tags they like that
the registry will accept. The MUST I'm adding does not forbid that.
It only clarifies the single distribution-spec Referrers Tag
associated with a given digest, because if there could be multiple
Referrers Tag for each digest, all distribution-spec
referrer-retrieving clients would have to iterate over that whole set
of possibilities, in case some distribution-spec referrer-pushing
client happened to use one of that digest's other Referrers Tag
formats.
[1]: dbb1434fd4/types/referrer/referrer.go (L157)
[2]: https://github.com/opencontainers/distribution-spec/pull/563#pullrequestreview-2599659231
Signed-off-by: W. Trevor King <wking@tremily.us>
The spec mandated only the verification of digests in the response
headers, not the requested digests. That allowed conformant clients not
to validate content at all, leaving the users of these clients exposed
to accidental or malicious bad content.
This commit adds a "SHOULD verify" clause to the blob and manifest pull
sections. It's not a MUST to keep it somewhat backwards compatible with
requirements of 1.1 and prior, but it's not a MAY to convey that "the
full implications should be understood and the case carefully weighed"
(description in RFC 2119) for a client not to verify digests.
This commit also aligns the recommendations for server-returned digests
between manifest and blob - now both can be ignored, but must be
verified if used.
Fixes: #549
Co-authored-by: Brandon Mitchell <git@bmitch.net>
Signed-off-by: Markus Rudy <mr@edgeless.systems>
OCI artifacts support has landed in various OCI specs v1.1.0 which
allows for arbitrary artifact types, small and large.
Large artifacts (even existing container images) pose a particular
challenge that:
1) it takes too long to download
2) it takes too long to unpack
This PR begins to address 1) above.
The client can initiate a HEAD request to get the size and later
multiple GET range requests to download a blob in parallel.
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
Updating tag listing to prefer the Link header.
This aligns with the behavior of actual registries, but will break clients implementing the current spec.
Breaking the spec was preferred over breaking existing registries and clients that work with them.
Signed-off-by: Brandon Mitchell <git@bmitch.net>
Happy to still be brought into conversations, but do not want to slow
progress of the active maintainers.
🐐🧁🧡
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Performing a teardown by tag requires support for a 400 (bad request) response.
The test tag is populated with manifest 4 which was already deleted, so remove the tag from the teardown.
Signed-off-by: Brandon Mitchell <git@bmitch.net>
