Open ianlewis opened 3 weeks ago
I'm kind of partial to 3 since that seems like the cleanest design and we can manage compatibility/stability of the token with the token version
. Though I realize it would add some overhead to changes in the SLSA token that forces us to bump the version (and maybe do a full major version bump for the whole project) if the SLSA token version changes.
For some ecosystems we will need to give the TRW the ability the affect the structure of the created SLSA predicate. This is blocking SLSA v1.0 support for the Node.js builder (#2499)
This is how it works currently:
setup-generic
actions creates a SLSA token in the context of the TRWverify-token
action and this creates a SLSA predicate based on the token. it also returns a verified version of the SLSA tokengenerate-attestations
action combinesverify-token
sign-attestations
actions takes the attestations returned bygenerate-attestations
and signs each using sigstore.Some potential solutions:
generate-attestations
step with their own implementation to alter the predicate created byverify-token
before signing.generate-attestations
step.update-attestation
) is added betweenverify-token
andgenerate-attestations
that allows TRWs modify the predicate before signing. It takes the predicate fromverify-token
and outputs a new predicate.verify-token
to be somewhat stable.verify-token
doesn't generate a predicate but just outputs a verified SLSA token. A separate step is added to generate the predicate (generate-predicate
) and TRWs can hook this action to generate their own predicate/buildType.verify-token
to be somewhat stable.