On OCI spec v2 registries, do not tag attestation manifests

[fmoessbauer]

Hi, while working on a container cleanup action (a proper one, not the package eater delete-package-versions), I noticed that special handling of the attestation data is required: The attestations are tagged according to the OCI spec v1 fallback defined in the cosign bundle spec, even when working on OCI spec v2 registries.

The problem hereby is, that the attestation manifests are tagged with sha256-<digest>, which makes them tagged images where special handling is needed. For OCI v2 registries (which support the referrers API), this is not needed (and discouraged), as the relation between the container and the attestation is purely done based on the "subject" part in the attestation manifest. This is picked up by the referrers API.

My proposal is to detect if the registry supports the referrers API (https://github.com/oras-project/artifacts-spec/blob/main/manifest-referrers-api.md#api-discovery) and conditionally create the tags.

Xref: dataaxiom/ghcr-cleanup-action#13

[bdehamer]

@fmoessbauer the scheme we're using to detect support of the referrers API is the one documented in v1.1 of the OCI spec and relies on the presence of the OCI-Subject header.

I believe the spec you linked to was a proposal but has now been superseded by OCI v1.1 (note that oras-project/artifacts-spec has been archived).

Are there specific registries you're testing with that support the Oras Artifact Spec but NOT the OCI 1.1 spec?

[fmoessbauer]

Hi @bdehamer : Thanks for providing the correct link to the spec. IIRC, the ghcr.io registry sets the OCI-Subject header.
From this perspective, the action behaves correctly.

My point is another one: The action in addition tags the attestations as sha256-<digest>, which is not ideal as then a special cleanup action is needed to remove these tags again - once the corresponding images are delete. This tag is only needed for pre-v1.1 registries and also should only be set there. This is at least how I interpret the cosign bundle spec.

[bdehamer]

@fmoessbauer Unfortunately, GHCR does NOT yet support the referrers API (and doesn't set the OCI-Subject header) so that's why you're seeing the sha256-digest tag in that registry.

I've done testing against a number of different registry implementations and the only ones I've encountered that have support for the referrers API are:

• Azure Container Registry
• zot
• CNCF Harbor

To be fair, OCI 1.1 was only formalized in the past few months so I'm hoping we'll soon see broader support for this feature.

This tag is only needed for pre-v1.1 registries and also should only be set there.

Strictly speaking, a registry can be OCI 1.1 compliant while NOT supporting the referrers API. Note that the 1.1 spec explicitly calls out the tag fallback scheme as a way for registries to support image-attached artifacts without implementing the referrers API.

The attestation action will only use the tag fallback in scenarios where it detects that the referrers API is not supported.