You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when using cosign download attestation, every attestation attached to the artifact is returned, which forces additional parsing to take place client-side using tools like jq to decode and filter out only the desired attestation (based on predicateType, for example). Adding support for annotations on artifact layers would achieve a few things:
It would make retrieval of the desired attestation using the cosign CLI trivial (cosign download attestation --annotation foo=bar <image>)
Verifying a particular attestation would also be trivial with cosign verify-attestation --annotation <image>
It would have the side effect of making the annotations visible as part of what gets returned by the v2 registry API, which means any language with basic support for making requests would be able to locate the desired attestation (albeit without attestation verification via cosign verify-attestatation)
This idea had been brought up before in #1773 and a PR was opened for it in #1934. That PR was ultimately closed due to concerns over how the annotation itself could be verified as part of the payload. I had suggested that perhaps the annotation is specified in both the manifest for the layer and in the payload itself. In this way, the annotation could be used to filter the desired layer without the need to download all attestations and decode them using an external tool like jq, and the verify-attestation would be performed by first validating the payload signature and then making sure the user-provided --annotation value matched the annotation in the signed payload.
I'd be willing to contribute a PR to try to provide this, if it sounds like a good idea.
The text was updated successfully, but these errors were encountered:
I’ve created #2484, which partially solves this by reusing the predicateType as an annotation on the attestation manifest. This exposes the predicateType to simple GET requests, which helps external tools not written in Go have an easier time of finding a particular attestation, and can also be used to be more selective about which attestation should be output with cosign download attestation —predicate-type <string>. Arbitrary annotations are probably still desirable for some use cases though.
Description
Currently, when using
cosign download attestation
, every attestation attached to the artifact is returned, which forces additional parsing to take place client-side using tools likejq
to decode and filter out only the desired attestation (based onpredicateType
, for example). Adding support for annotations on artifact layers would achieve a few things:cosign
CLI trivial (cosign download attestation --annotation foo=bar <image>
)cosign verify-attestation --annotation <image>
v2
registry API, which means any language with basic support for making requests would be able to locate the desired attestation (albeit without attestation verification viacosign verify-attestatation
)This idea had been brought up before in #1773 and a PR was opened for it in #1934. That PR was ultimately closed due to concerns over how the annotation itself could be verified as part of the payload. I had suggested that perhaps the annotation is specified in both the manifest for the layer and in the payload itself. In this way, the annotation could be used to filter the desired layer without the need to download all attestations and decode them using an external tool like
jq
, and theverify-attestation
would be performed by first validating the payload signature and then making sure the user-provided--annotation
value matched the annotation in the signed payload.I'd be willing to contribute a PR to try to provide this, if it sounds like a good idea.
The text was updated successfully, but these errors were encountered: