add OCI artifact version of attestation manifest #5573
Conversation
This adds a new exporter option oci-artifact. If set then it changes the attestation manifest to be exported with following changes: - subject field is added to attestation manifest - config uses empty descriptor instead of fake image config - artifactType property is set The intention is to change this behavior from opt-in to opt-out in some future release when target is OCI image. Signed-off-by: Tonis Tiigi <[email protected]>
tonistiigi
force-pushed
the
oci-aftifact-attestation
branch
from
37d5e8b to
0251a3d
Compare
|
Thanks for getting this started! There's some fallback logic the spec requires when this is pushed to a registry without the referrers API. We have that documented at: https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pushing-manifests-with-subject ETA: here's what that fallback tag would look like with a single entry: https://explore.ggcr.dev/?image=sudobmitch%2Fdemo:sha256-bc2046336420a2852ecf915786c20f73c4c1b50d7803aae1fd30c971a7d1cead |
|
I see this as more of an intermediate change -- the attestation still ends up in the index, which is the current means of discoverability, it's just now annotated with an appropriate subject so that when referrers are implemented, it shows up in the API (and so that the link between the attestation and its manifest is clear in the data model). Once referrers are implemented more universally (especially Docker Hub, but perhaps others?), then we can think about removing them from the index too. In other words, I don't see a reason to implement the fallback tags here. (IMO the spec ought to say SHOULD there instead of MUST, but that comes from a place of thinking the fallback is a really poor compromise for UX and the upsides don't outweigh the down. To be very explicit, if buildkit/buildx implements the fallback behavior, I'll be patching it out in my own builds and/or pushing in a way that doesn't involve the fallback logic.) |
|
We had made it a "must" because registries are not required to support the referrers response for content pushed before the server is upgraded if it doesn't also have the fallback tag. If buildkit pushes content without the fallback support, it may not be discovered when a registry later supports the referrers API. This was a concession for large registries like Docker Hub that may have a lot of content they don't want to rescan. Registries can assume well behaved clients, and only need to rescan the small percentage of manifests referenced by a fallback tag. If large registries no longer have the concern about rescanning all of the pre-existing content, we could propose a change to the spec from a "client must" to a "registry must". Ref: https://github.com/opencontainers/distribution-spec/blob/main/spec.md#enabling-the-referrers-api |
|
Thanks @tonistiigi. This is a great first step. Making this opt-in is a good solution to prevent registries that don't yet support/accept a Implementing the fallback mechanism and eventually using that for DOI (although @tianon indicated he wouldn't, so this is theoretical) would have quite a few negative effects and surprises for our users on Docker Hub. Again, great addition. |
fixes #5561
This adds a new exporter option oci-artifact. If set then it changes the attestation manifest to be exported with following changes:
The intention is to change this behavior from opt-in to opt-out in some future release when target is OCI image.
Example https://explore.ggcr.dev/?image=docker.io/tonistiigi/buildkit@sha256:bf8355824354aee83a9874f7178ea91a17752603a949e89f00f9e3ca5404db35&mt=application%2Fvnd.oci.image.manifest.v1%2Bjson&size=915
Quick test: