feat(attest): custom annotations support

[developer-guy]

Signed-off-by: Batuhan Apaydın [email protected]

Summary

This PR will add custom annotation support to both attest and verify-attestation commands.

Ticket Link

Fixes #1773

Release Note

feat(attest): custom annotations support

[dlorenc]

Just to make sure I understand, the annotations don't make it into the attestation, they're stored separately on the OCI object right?

[developer-guy]

If I understand correctly, the answer should be yes but PTAL @asraa

[asraa]

Yeah! That's correct. They're unsigned, just useful for extra metadata that might help for location or organization.

LGTM

[codecov-commenter]

Codecov Report

Merging #1934 (ee0e82a) into main (68e8d93) will decrease coverage by 0.02%. The diff coverage is 22.22%.

@@            Coverage Diff             @@
##             main    #1934      +/-   ##
==========================================
- Coverage   28.71%   28.68%   -0.03%     
==========================================
  Files         132      132              
  Lines        8087     8111      +24     
==========================================
+ Hits         2322     2327       +5     
- Misses       5458     5475      +17     
- Partials      307      309       +2     

Impacted Files	Coverage Δ
cmd/cosign/cli/attest.go	0.00% <0.00%> (ø)
cmd/cosign/cli/options/attest.go	0.00% <0.00%> (ø)
cmd/cosign/cli/options/verify.go	0.00% <0.00%> (ø)
cmd/cosign/cli/verify.go	0.00% <0.00%> (ø)
cmd/cosign/cli/verify/verify_attestation.go	0.00% <0.00%> (ø)
pkg/cosign/verifiers.go	50.00% <46.15%> (-2.28%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 68e8d93...ee0e82a. Read the comment docs.

[dlorenc]

Hmm, if they're unsigned them I'm a little worried about how this works, we can't verify them using the verify flag, can we?

Could you describe the use case a bit more? I'd be more comfortable if we could get them into the attestation

[developer-guy]

@asraa, I think we need your assistance here 🙋🏻‍♂️

[developer-guy]

kindly ping @asraa

[asraa]

Hey! Ah sorry, originally, we wanted to add tags on who created the attestation (e.g. this came from a github reusable workflow), and use that as a hint to verify, but we also include that in the attestation itself, like you said, so we do end up verifying that content. It's not strictly needed, but it was really confusing that cosign exposes annotations but does not verify them consistently.

https://github.com/sigstore/cosign/blob/6eeb3cf5864edf34d87084c3f942d4a9a36a54ce/cmd/cosign/cli/sign.go#L48

Maybe this PR can nuke the -annotation checks anyway?

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions[bot]]

This PR was closed because it has been stalled for 10 days with no activity.

[bburky]

Today the predicateType is inside the signed payload, inside the attestation layers themselves. If there are multiple attestation types, it is not possible to pull the manifest and select which attestations to download.

This feature is interesting to me because it would allow providing a custom hint for which layers contain a specific attestation. Alternately, a predicateType could be added as a standard cosign annotation to support this too if this is desirable.

If I understand correctly, today cosign has to filter attestation types after downloading every attestation layer and inspecting the predicateType inside the payload? A hint in the annotations allows optimizing to only download the needed attestations.

[chaospuppy]

This seems like a really useful feature in order to avoid the need to decode and parse each layer of an attestation until the desired predicateType is located, as @bburky described. This limitation presents a substantial challenge to tools looking to retrieve attestation payloads that are built using languages without cosign libraries available in their ecosystem. @dlorenc would it work if the predicateType was added as an attestation to the layer e.g.:

"layers": [
    {
      "mediaType": "application/vnd.dsse.envelope.v1+json",
      "size": 11452,
      "digest": "sha256:09ca22f4ce6e85c40a8a68ec0f402caeb0e815c9b21e2447c246880d2533c995",
      "annotations": {
        "dev.cosignproject.cosign/signature": ""
        "predicateType": "https://cyclonedx.org/schema"
      }
    }
  ]

Then, part of the verification process when a --predicate-type is specified as part of cosign download attestation command (e.g. cosign download attestation --predicate-type https://cyclonedx.org/schema) , the signed predicateType value included in the payload could be compared with the user-supplied --predicate-type value after the layer is located using the annotation, and verification could be failed if the values don't match. Thoughts?

[developer-guy]

Can we re-open this one @dlorenc if you still consider it useful?