Verify multiple local bundle attestations
Description
I noticed a difference in behavior between cosign verify-attestation <oci reference> and cosign verify-blob-attestation <blob> --bundle attestation.json:
- The OCI implementation finds all attestations that refer to the artifact and verifies all of them.
- The local blob implementation accepts only a file with a single blob in it.
Questions:
- Should local blob verification support a single jsonl with multiple attestations in it, possibly with different signing identities?
- Should local blob verification support multiple
--bundle bundle1.json --bundle bundle2.jsonoptions to verify an explicit set in one go?
Related #4494.
Note - I think I remember hearing some talk years ago about deprecating the pattern where multiple attestations were written to the same image manifest (kind of like the OCI equivalent of a jsonl file) because of a multiple-writers TOCTOU problem. That's why the OCI attestations are separate OCI artifacts linked only by the referrer's API.
A local .jsonl file would have a similar problem in theory if, somehow, multiple writers in a system were all trying to append to it at the same time without taking precaution to be safe. AFAIK, multiple processes appending to the same file in parallel with >> is safe.
What is your use case for verifying multiple attestations in one command rather than re-running cosign verify-blob-attestation for each attestation?
An end-user definitely could just wrap cosign verify-blob-attestation in a little loop.
In the end, I think it's about convenience and what kind of pattern the tooling encourages. Do we want to encourage multiple sigstore attestation bundles per artifact? I think we do; at least, SLSA provenance and SBOM. There could be as many as there are well known predicates and more. (Reality check: I think, at present, most projects today are not producing more than one attestation for artifact.)
I suppose its also about consistency. If verify-attestation operates on the list of attestations discovered by the OCI referrer's API, then arguably verify-blob-attestation should operate on a list of attestations if such a list is found in the provided bundle filename. If we'd prefer to verify only single blobs per invocation, then perhaps the OCI variant in verify-attestation should be modified to match -- to require specifying exactly which attestation is to be verified, rather than assuming and acting on the discovered list from the referrer's API.