Description
Feature Overview
Would be nice to have support for verifying signatures/provenance for executables coming from inside archives. Currently it seems aqua can verify only the downloaded assets as-is.
Why is the feature needed?
Example case in https://github.com/kubewarden/kwctl: GH artifact attestations are generated, but only for executables that are put within archives, not the archives themselves.
- https://github.com/kubewarden/kwctl/blob/2dbab69752a2447a1dac767e17596246d5816b10/.github/workflows/build.yml
- https://github.com/kubewarden/kwctl/releases/tag/v1.23.0
- https://github.com/kubewarden/kwctl/attestations
This practice is not that widespread at the moment at least with GH attestations I believe (kwctl is the first I met it with), but coincidentally I happened to think of it being a good practice already some time ago: it enables re-verification of already installed binaries afterwards.
I suppose this would be applicable at least some other signing/provenance types besides GH attestations as well.
Known projects using this type of attestations:
- https://github.com/foundry-rs/foundry/attestations
https://github.com/foundry-rs/foundry/releases/tag/nightly-f76309dad7dddc0917755d3f3d17e1ad9d02c6b8
https://github.com/foundry-rs/foundry/blob/1ae64e38a1c69bda45343947875f7c86bad00038/.github/workflows/release.yml#L244-L251 - https://github.com/kubewarden/kwctl/attestations
https://github.com/kubewarden/kwctl/releases/tag/v1.23.0
https://github.com/kubewarden/kwctl/blob/2dbab69752a2447a1dac767e17596246d5816b10/.github/workflows/build.yml
Example Code
Configuration
# maybe files could be used/extended for this?
files:
- name: example
github_artifact_attestations:
signer_workflow: ...Note
No response