feat: add OCI 1.1 Referrers API support with configurable encoding format

[anithapriyanatarajan]

NOTE TO REVIEWERS: Originally this PR intended to allow a user-configurable approach for both distribution and serialization. During later review and iterative testing it became clear this adds needless complexity for users, and we additionally discovered via sigstore/cosign#4841 that the sigstore-bundle + DSSE combination is not supported in cosign. The PR therefore distills to two simple scenarios behind a single config knob, summarized below.

Changes

Chains currently stores all OCI signatures and attestations using a tag-based scheme (sha256-<digest>.sig / .att). This creates extra tags in the registry for every signed artifact. This PR adds support for the OCI 1.1 Referrers API as an alternative storage mechanism.

New configuration key

A single new key controls both the serialization format and the distribution mechanism. They are intentionally coupled — not separately configurable:

Key	Values	Default
storage.oci.encoding-format	dsse, sigstore-bundle	dsse

Possible Scenarios:

encoding-format	Encoding	Behaviour
dsse	DSSE envelope	Tag-based storage (.sig / .att tags) — unchanged default
sigstore-bundle	Sigstore protobuf bundle	OCI 1.1 Referrers API — no .sig / .att tags

dsse + protobuf-bundle and sigstore-bundle + DSSE are intentionally not offered: cosign's verification for referrer-stored attestations expects the protobuf bundle, and sigstore-bundle exists precisely to move away from the legacy tag layout, which has downsides:

• The registry fills up with extra tags that aren't real images.
• These tags are easy to confuse with actual image tags.
• No OCI standard describes this layout, so every tool has to special-case it.

This keeps the surface to one knob and avoids a confusing matrix of combinations, some of which no tool can verify.

Backward compatibility

All existing deployments with no OCI encoding format config set continue to behave identically (dsse + tag-based). No action required.

Implementation

• config.go — OCIStorageConfig gains an EncodingFormat field; new constants (OCIEncodingFormatDSSE, OCIEncodingFormatSigstoreBundle) and a validateOCIEncodingFormat validator. Defaults to dsse when unset.
• options.go — New WithEncodingFormat() option function; houses the referrersRepoOverrideIgnored helper.
• attestation.go / simple.go — Dispatch keys off encodingFormat; sigstore-bundle writes attestations as a protobuf bundle via ociremote.WriteAttestationNewBundleFormat, while signatures use cosign's native signature referrer.
• legacy.go — Backend passes WithEncodingFormat when constructing storers.
• signing.go / signing/iface.go — signing.Bundle and StorageOpts gain a PublicKey crypto.PublicKey field; PublicKey() extraction after signing is non-fatal (logs a warning, storage continues) so KMS signers don't break the default path. Also wires up Rekor bundle population before storage so the bundle annotation is available for offline verification.

Tests

• config_test.go — Tests the default, valid/invalid values for encoding-format, and the validateOCIEncodingFormat validator.
• oci_test.go — Tests WithEncodingFormat, empty defaults, the Backend config, and that storage.oci.repository override is ignored in sigstore-bundle mode.
• store_test.go — Updated defaultStorage to reflect the struct field rename.
• attestation_test.go / simple_test.go — Tests for the sigstore-bundle store path including dedup.
• referrers_api_e2e_test.go (new) — E2E tests for TestOCIStorageSigstoreBundle_TaskRun and TestOCIStorageSigstoreBundle_PipelineRun.

Docs

• oci-artifact-distribution-format-referrers-schema.md (new) — Tutorial-style page explaining the Referrers schema, how cosign and Chains enable it, why referrers + protobuf bundle (not DSSE), registry compatibility, and verification examples.
• config.md — New storage.oci.encoding-format row in the storage configuration table.

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

feat: OCI storage now supports the OCI 1.1 Referrers API via a new config key:

  storage.oci.encoding-format: dsse (default) | sigstore-bundle

- dsse: tag-based storage with DSSE envelope The as-is unchanged behaviour, no action required.
- sigstore-bundle: stores attestations as a Sigstore protobuf bundle via the OCI 1.1
  Referrers API, eliminating sha256-*.sig / *.att tag proliferation in your registry

/kind feature

Co-Authored-by: Copilot (Claude Sonnet 4.6)

[tekton-robot]

@anithapriyanatarajan: The label(s) kind/enhancement cannot be applied, because the repository doesn't have them.

Details

In response to this:

Changes

Chains currently stores all OCI signatures and attestations using a tag-based scheme (sha256-.sig / .att). This creates extra tags in the registry for every signed artifact. This PR introduces support for the OCI 1.1 Referrers API as an alternative storage mechanism, plus independent control over payload serialization format, making both dimensions separately configurable.

New configuration keys

Two new keys introduced to replace the old monolithic approach:

Key	Values	Default
storage.oci.distribution-method	legacy, referrers-api	legacy
storage.oci.serialization-format	dsse, protobuf-bundle	dsse

Valid combinations:

distribution-method	serialization-format	Behaviour
legacy	dsse	Tag-based storage, DSSE encoding — unchanged default
referrers-api	dsse	OCI 1.1 Referrers API, DSSE encoding — fewer tags
referrers-api	protobuf-bundle	OCI 1.1 Referrers API, Sigstore protobuf bundle (experimental)

legacy + protobuf-bundle is rejected at startup with a clear error.

Backward compatibility

All existing deployments with no OCI config set continue to behave identically.

Implementation

• config.go — OCIStorageConfig gains DistributionMethod and SerializationFormat fields; new constants (OCIDistribution*, OCISerialization*); independent validators plus a combination validator.
• options.go — New WithDistributionMethod() and WithSerializationFormat() option functions replacing the former WithFormat().
• attestation.go / simple.go — Dispatch logic updated; new storeWithReferrersAPI() and storeWithProtobufBundle() methods on both storers using ociremote.WriteAttestationsReferrer / ociremote.WriteAttestationNewBundleFormat.
• legacy.go — Backend passes both new options when constructing storers.
• signing.go / signing/iface.go — signing.Bundle and StorageOpts gain a PublicKey crypto.PublicKey field; PublicKey() extraction after signing is non-fatal (logs a warning, storage continues) so KMS signers don't break the legacy path.
• options.go — StorageOpts.PublicKey field added.

Tests

• config_referrers_test.go (new) — Tests defaults, valid/invalid values for each key, the invalid combination, and backward-compat migration.
• referrers_test.go (new) — Tests WithDistributionMethod, WithSerializationFormat, empty defaults, and the Backend two-field config.
• store_test.go — Updated defaultStorage to reflect the two-field struct.

Docs

• oci-storage-formats.md (new) — Full reference page explaining both keys, the valid combination matrix, per-format details, registry compatibility, and verification examples.
• config.md — Two new rows in the storage configuration table.

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

feat: OCI storage now supports the OCI 1.1 Referrers API and Sigstore protobuf bundle serialization via two new independent config keys:
 storage.oci.distribution-method: legacy / referrers-api   (default: legacy)
 storage.oci.serialization-format: dsse / protobuf-bundle  (default: dsse)
Setting distribution-method: referrers-api eliminates the sha256-*.sig / *.att tag proliferation in your registry. The default (legacy + dsse) is unchanged - no action required for existing deployments.

NOTE: This original PR that attempted to address this scenario was #1409. With consensus from the author @arewm this PR is being progressed to address the same functionality. If this PR is merged, #1409 could be closed.

/kind enhancement

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[anithapriyanatarajan]

@tektoncd/chains-collaborators @arewm - Please review and share your comments. Thank you

[anithapriyanatarajan]

Detailed steps to test and observations are captured here for reference - https://gist.github.com/anithapriyanatarajan/b112638e7b3d78ee6638c6fec4f51bc8

Observed Gaps, which would be analyzed further with appropriate follow ups:

1. cosign verify discoverability (used cosign 3.0.3): the signature path uses the low-level WriteReferrer. Switching to cosign-native WriteSignaturesExperimentalOCI would let cosign verify reverse-discover signatures directly. Scoped as a follow-up to keep the storage PR focused. Update NOTE: Fixed in [commit] (4d43d45) - this should no more be a problem

2. quay.io read path: write succeeds but referrers aren't returned on read. Registry-side bug, not a Chains issue. The functionality was completely verifiable if we target ghcr.io. we may need to check the status of other registries and add to the release notes.

Registry readiness for OCI 1.1 is much critical to realize the benefit of this PR for users.

[ab-ghosh]

Just want to confirm, here we are using req.Artifact, which drops the override of repo and ignores the storage.oci.repository. Should we use the overridden repo instead?

[anithapriyanatarajan]

More details on why we are doing this change - sigstore/docs#411 & kubernetes-sigs/tejolote#639

[jkhelil]

@anithapriyanatarajan
Does the PR handles automatically fall back to the legacy tag schema when a registry does not support the OCI 1.1 Referrers API, so that storage.oci.format=referrers can be safely configured without knowing the registry's OCI 1.1 support status.

[jkhelil]

@anithapriyanatarajan can you add e2e tests ?

[anithapriyanatarajan]

@anithapriyanatarajan Does the PR handles automatically fall back to the legacy tag schema when a registry does not support the OCI 1.1 Referrers API, so that storage.oci.format=referrers can be safely configured without knowing the registry's OCI 1.1 support status.

@jkhelil - Yes, storage.oci.format=referrers-api can be safely configured without knowing the registry's OCI 1.1 support status. The fallback to the Referrers Tag Schema is handled automatically by go-containerregistry (the underlying library used by cosign and vendored in Chains). If the registry natively supports the Referrers API (e.g., Quay), it is used directly. If not, go-containerregistry automatically falls back to storing referrers as an OCI Image Index tag, per the OCI distribution spec mandate (spec lines 777–806). Since this fallback is transparent at the library level, Chains does not need to implement its own fallback logic, and users do not need to manually revert to the legacy storage format based on registry capability. I have verified this behavior with quay and ghcr. For quay it takes the referrers API path while for ghcr it takes the referrers tag path. Will share evidences after fixing a few other findings. Thank you

[anithapriyanatarajan]

@anithapriyanatarajan can you add e2e tests ?

Done

[jkhelil]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jkhelil

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [jkhelil]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[anithapriyanatarajan]

@jkhelil - I would like to reiterate to see the feasibility of accommodating #1691 (comment). Hence marking this as work in progress.

[anithapriyanatarajan]

Manual test evidence

Tested manually on a kind cluster across four configurations of storage.oci.encoding-format, using the same TaskRun for each. Environment: kind + registry(quay.io/rh-ee-anataraj), cosign v3.1.1, transparency enabled but tlog entries were not made (so cosign verify* is run with --insecure-ignore-tlog=true; the tlog skip is expected in this env, not a failure).

Full write-up with every command and its output (cosign tree/verify/verify-attestation, cosign download, oras discover, crane manifest for the image/signature/attestation) is attached below for reference
Chains output Analysis - Impact of Referrer's API changes.pdf

Summary

Scenario	storage.oci.encoding-format	Storage layout	Payload format	.sig/.att tags	oras discover
1. main (pre-PR baseline)	unset	tag-based	DSSE	created	empty
2. PR branch, key unset	unset (implicit)	tag-based	DSSE	created	empty
3. PR branch, explicit	dsse	tag-based	DSSE	created	empty
4. PR branch, referrers	sigstore-bundle	OCI 1.1 Referrers API	Sigstore protobuf bundle	none	populated

Scenarios 1–3 confirm the default/legacy path is unchanged (no behavior change when the key is unset or set to dsse). Scenario 4 is the new path.