Open Container Initiative announces upcoming changes for registries(chainguard.dev)
chainguard.dev
Open Container Initiative announces upcoming changes for registries
https://www.chainguard.dev/unchained/oci-announces-upcoming-changes-for-registries
10 comments
https://news.ycombinator.com/item?id=36713961 appears to be the submission for the actual url, if we wanted to upvote that one in place of this, or even merge the comments
So this is a new version of the OCI image spec, with some changes that will affect container image registries? (I'm having a little bit of trouble interpreting the article)
Yep - a new version of image spec and distribution spec (not runtime spec).
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.
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.
> 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.
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).
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).
SBOMs may be an important short-term use-case, but ultimately the spec will now provide a "blessed" way to attach even a cat picture. It can be uploaded standalone or pointing to a container image.
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.
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.
The ability to ask for (and upload) "related" media sounds so much like WebFinger (rfc7033)'s JSON Resource Descriptors (JRD's).
'Hey-- this url? Do you have any media related to it?'
https://datatracker.ietf.org/doc/html/rfc7033#section-3.2
'Hey-- this url? Do you have any media related to it?'
https://datatracker.ietf.org/doc/html/rfc7033#section-3.2
For a number of reasons this might not have been a good choice for OCI:
- Repositories in the registry are namespaced under /v2/<name>/...
- Legacy clients already support parsing OCI manifests (vs. WebFinger JSON)
- Repositories in the registry are namespaced under /v2/<name>/...
- Legacy clients already support parsing OCI manifests (vs. WebFinger JSON)
[deleted]
I was hoping this post would be about Oracle... smh
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.