@lcarva - right now we do not set any annotation on tekton objects post storage with other backend types. Is there any concern having the info captured post upload?

I haven't reviewed the PR yet, but this is what comes to mind:

Chains will add annotations once it is done processing a Tekton object (TaskRun or PipelineRun). That happens right at the end of reconciliation. This update triggers another reconciliation but that's generally ok because Chains quickly detects the object has already been processed (based on it annotations) and skips that iteration of the reconciliation loop.

If Chains updates the Tekton object before those final annotations are added, the reconciliation that is triggered as a side-effect will cause signing and attesting to happen again. This may happen multiple times.

I would advise against changing the object during reconciliation. If needed, try tying into the already existing mechanism Chains has for adding the final annotations, see here.

NOTE: The tekton storage does update the object during reconciliation. We should probably fix that, but that's less of a concern given that that storage type is meant for test/develop.

@lcarva Are you suggesting that tekton storage should not be used in production? Isn't it included in some of the default configuration?

It might be best for us to remove this for now and follow up with the annotation in a separate PR. cc @mikhailswift

Are you suggesting that tekton storage should not be used in production?

Yes, 100%. This storage stores payloads as annotations which can get quite large if you have a pipeline with many tasks, for example. You'll face etcd issues eventually.

Isn't it included in some of the default configuration?

Yes, it's not ideal. We could pursue changing this default to OCI which is a more suitable storage type that requires no configuration if you are already building container images.

The annotations have been removed from the Archivista storage backend

@mikhailswift could you please help with the steps a user has to perform with cosign to verify-blob-attestation or verify-attestation accessing the uploaded content from archivista?

I think it would be nice to create an issue in Archivista project where it can have a function to retrieve the data

cc @lcarva @wlynch

I think the main thing we need here is details of what Tekton uses to retrieve the data. I looked into it a bit and I am a bit unclear on what the ShortKey is that is being used to find the payload.

Archivista can search for payloads with its GraphQL API and download the DSSE envelope. From Archivista's side, we need to make sure we are indexing the ShortKey or some other identifier that Tekton will use to retrieve the payload.

@mikhailswift - Please lookup - https://github.com/tektoncd/chains/blob/main/pkg/config/options.go#L26C1-L36C1. Does this help?

// ShortKey is the short version of an artifact identifier. This is useful for annotation based storage
// because annotation key has limitations (https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set).
// - For OCI artifact, it is first 12 chars of the image digest.
// - For TaskRun/PipelineRun artifact, it is `<KIND>-<UID>`.
ShortKey string

Yeah, I think this helps. One thing I'm not entirely clear on -- does the UID appear in the in-toto attestation payload?

If so archivista can easily just look for that and put it in a searchable edge off of the DSSE envelope

FYI, the Retrieve* functions are only used as part of the tkn chain CLI tool. They're not that useful and I'd be shocked if anyone actually uses it. So I think it's fine to leave these as not implemented.

FYI, the Retrieve* functions are only used as part of the tkn chain CLI tool. They're not that useful and I'd be shocked if anyone actually uses it. So I think it's fine to leave these as not implemented.