`verify-attestation` failure since 1.10.1 when no predicate type specified

[chipzoller]

Description

Since Cosign 1.10.1, the ability to perform a cosign verify-attestation on a keyless-signed image containing attestations of multiple predicate types returns main.go:62: error during command execution: none of the attestations matched the predicate type: custom. The help output for the verify-attestation command indicates this is still a valid command so I'm confused on the current behavior. Does this represent a regression or a change in how the command works?

Cosign 1.10.0 output

$ COSIGN_EXPERIMENTAL=1 ./cosign110 verify-attestation ghcr.io/chipzoller/zulu:v0.0.13

Verification for ghcr.io/chipzoller/zulu:v0.0.13 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - Any certificates were verified against the Fulcio roots.
Certificate subject:  https://github.com/chipzoller/zulu/.github/workflows/vulnerability-scan.yaml@refs/heads/main
Certificate issuer URL:  https://token.actions.githubusercontent.com
Certificate extension GitHub Workflow Trigger: schedule
Certificate extension GitHub Workflow SHA: b3ef2d0b63ea9f0422367944c8cbb7b0f75389c0
Certificate extension GitHub Workflow Name: vulnerability-scan
Certificate extension GitHub Workflow Trigger chipzoller/zulu
Certificate extension GitHub Workflow Ref: refs/heads/main
{"payloadType":"application/vnd.in-toto+json","payload":"eyJfdHlwZSI6Imh<snip>

Cosign 1.10.1 output

$ COSIGN_EXPERIMENTAL=1 ./cosign1101 verify-attestation ghcr.io/chipzoller/zulu:v0.0.13
Error: none of the attestations matched the predicate type: custom
main.go:62: error during command execution: none of the attestations matched the predicate type: custom

Cosign 1.11.0 output

$ COSIGN_EXPERIMENTAL=1 ./cosign1110 verify-attestation ghcr.io/chipzoller/zulu:v0.0.13
Error: none of the attestations matched the predicate type: custom
main.go:62: error during command execution: none of the attestations matched the predicate type: custom

Cosign 1.12.0 output

$ COSIGN_EXPERIMENTAL=1 cosign verify-attestation ghcr.io/chipzoller/zulu:v0.0.13
tuf: warning using deprecated ecdsa hex-encoded keys
tuf: warning using deprecated ecdsa hex-encoded keys
tuf: warning using deprecated ecdsa hex-encoded keys
<snip>
Error: none of the attestations matched the predicate type: custom
main.go:62: error during command execution: none of the attestations matched the predicate type: custom

Version

1.12.0

[asraa]

Was this a regression due to https://github.com/sigstore/cosign/commit/c5fda01a8ff33ca981f45a9f13e7fb6bd2080b94?

It seems related, but haven't checked the internals. @mattmoor

[mattmoor]

There isn't a form of verify-attestation that checks all/multiple predicate types.

The predicate type defaults to custom, but verify-attestation was previously reporting success (for ANY predicate type) if there were attestations with valid signatures, even if there isn't one for the specified (or defaulted) predicate type. This was the CVE that commit fixed.

Now cosign verify-attestation --type=foo will only report success if the image has an attestation signed appropriately with the predicate type foo (where foo is custom by default).

[mattmoor]

Here is the GHSA which contains more: https://github.com/sigstore/cosign/security/advisories/GHSA-vjxv-45g9-9296

[chipzoller]

So with this fix in place, what would be the approach to get a valid return to the question, "show all of the attestations for image foo"? Also, if --type is now required, might want to change the output of the help command.

[asraa]

Agree that if --type is not specified, all valid attestations probably should return

[chipzoller]

As a user, that's what I would expect because one cannot know which attestations and their types may exist.

[mattmoor]

I would recommend adding an all value for --type, and (personally speaking) would also be fine with that being the default.

However, to illustrate my point:

cosign verify-attestation foo

... is indistinguishable from:

cosign verify-attestation --type=custom foo

... and what we were doing before was very wrong for the latter.

[mattmoor]

This gets doubly true when policy arguments are passed to run over attestations matching the type 😅

For --type=all we would need to think through those arguments behaviors, and possible disallow them.

[chipzoller]

We're seeing attestation failures in Kyverno 1.8.0, presumably related to this issue: https://github.com/kyverno/kyverno/issues/4819

[developer-guy]

https://github.com/tektoncd/chains/pull/581 https://github.com/buildsec/frsca/pull/322

[JimBugwadia]

@mattmoor the all would be useful when external policy is applied and will help reduce calls when multiple types are checked The other option that would work is to take a list of types and return all that match.

[developer-guy]

I can take care of this one ☝️🫡

[chipzoller]

That would be great, @developer-guy. This is definitely needed for cosign, but regarding my comment here, after some investigation, we think these failures might be due to a Kyverno change and not a Cosign one. Nevertheless, I think it's quite important that users and tooling be able to get all attestations which are valid for an image without knowing and requesting the exact predicate types available.

[datosh]

Any update on this @developer-guy ? Just tried to follow anchore's blog post on this topic, and verify step fails without specifying the --type which is quite convoluted to find in the first place:

cosign download attestation <image_ref> | jq -r .payload | base64 -d | jq .predicateType

[chipzoller]

Bump