Open Container Initiative announces upcoming changes for registries
chainguard.dev
chainguard.dev
The important link is here: https://opencontainers.org/posts/blog/2023-07-07-summary-of-...
And with that knowledge you can go check your registry about their timeline on adopting these changes.
This version allows for formalized ways to store other types of content in registries (think Helm Charts, OPA policies, etc.), as well as a way to "attach" arbitrary content to registries and then retrieve it later.
Both of these are powerful and will have lots of use cases, but the primary ones at this point are focused on supply chain security - storing content like SBOMs, digital signatures and attestations.
First part seems right. I think though that part two is maybe misworded or what not? It allows artifacts of any kind to ne attached/related to other artifacts.
From the oci blog post, the example is uploading a software-bill-of-material sbom & having it attached to the container it represents. Such that a user can then query of there is an sbom for their container & get a list of such sboms (you can also ask for an index of all related content).
The way to indicate a non-container artifact type is to use the "artifactType" field. Your client may choose whether or not to support older <=v1.0 registries by falling back to use "config.mediaType". The way to attach the artifact to the image is to use the "subject" field, pointing "subject.digest" to the proper digest of the thing you're pointing to (e.g. "sha256:..." ). There are no limitations there either, you may point cat pictures to cat pictures.
'Hey-- this url? Do you have any media related to it?'
- Repositories in the registry are namespaced under /v2/<name>/...
- Legacy clients already support parsing OCI manifests (vs. WebFinger JSON)