Add support for passing multiple subject-name/subject-digest pairs

[vlsi]

For security reasons, id-token: write, attestations: write and other privilege usages should be minimized, so the privileges should not exist for code that performs "build" steps.

In other words, the best usage would be splitting the build+attest into separate steps:

1. build artifacts (without id-token: write)
2. attest the results

However, then the users would have to transfer the artifacts from build to the attest job.
Of course they can make a zip file, publish it from "build artifacts", download it in the attest job, and perform the attestation.
That would be wasteful though as the only needed bit is SHA of the file, so it would be better to generate a list of filename-checksum pairs in the "build artifact" job, and use the list in "attest the results" job.

What do you think of adding @actions/upload-checksums action that would generate checksums for the specified files. Then @actions/attest-build-provenance could use the list and generate the attestations for them?

[aalmiray]

FWIW subject-path already supports multiple subjects though it does not seem to be documented as such.
It would also be great if a file containing subject paths were to be supported as input. Specifically JReleaser computes a list of release assets that should be attested

https://jreleaser.org/guide/early-access/reference/catalog/github.html

[bdehamer]

@vlsi this seems like a useful feature (and we've received a few other similar requests already). We'll consider this for the next round of improvements to the attestation actions. Thanks!

[bdehamer]

@vlsi / @aalmiray version 2.2.0 of the action supports a new subject-checksums input parameter which will accept a path to a checksums file. The checkums file generated by tools like GoReleaser, JReleaser, or the shasum CLI can now be used as a way to identify the subjects of your attestation.

See details in README

[aalmiray]

Thank you @bdehamer, this is quite useful! 🥳