Consider the new Artifact support in OCI Spec v1.1

[ThomasVitale]

The upcoming OCI Image and Distribution Specs v1.1 will include changes that might be relevant for imgpkg. The goal is to standardise the way OCI is used to store arbitrary artifacts.

The OCI Image Spec 1.1 will introduce a new artifactType that can be used attached to a manifest to describe what artifact is included in the bundle instead of the current approach based on pushing artifacts with name <digest>.<suffix> (where <suffix> would be imgpkg, sig, att, sbom...).

• Summary of Upcoming Changes in OCI Image and Distribution Specs v1.1 (OCI)
• OCI Artifact Usage Guidelines (OCI)
• Background: Intro to OCI Reference Types (Chainguard)
• Background: Building towards OCI v1.1 support in cosign (Chainguard)
• Background: OCI announces upcoming changes for registries (Chainguard)

The OCI Distribution Spec 1.1 will introduce support for querying artifacts based on a specific artifactType value and for establishing relationships among artifacts belonging to the same entity (so to handle together main artifact, signature, attestation, sbom... all together).

From what I see, imgpkg would be at least impacted in its functionality to transfer cosign signatures together with OCI images. It will also impact the implementation of #269. Also, there's an opportunity to use the new format and mark an OCI artifact as an imgpkg bundle using the new artifactType field rather than the .imgpkg suffix + custom labels on the manifest.

In the future, also vendir and kapp-controller might need to consider these changes when getting to work on carvel-dev/vendir#92 and carvel-dev/kapp-controller#1078.

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help work on this issue.

[joaopapereira]

Yes, this is something that we will need to support in the future, we need to wait for go-containerregistry to get up to date, and this will become more important as soon as cosign moves to artifacts itself. At that point, our current implementation of signature copy and retrieval is no longer valid.

Going to mark it as Carvel accepted, but we need to wait for go-containerregistry to adopt the new spec first

[ThomasVitale]

The go-containerregistry project is currently asking for feedback about the OCI 1.1 changes in google/go-containerregistry#1750.

We also need to wait for container registries to start adopting the new spec. So far, I only know about Zot and Azure Container Registry which already provide support for it.