search

slsa-framework / slsa-github-generator

Language-agnostic SLSA provenance generation for Github Actions
Apache License 2.0
412 stars 127 forks source link

[feature] Output provenance as Sigstore bundle format #3750

Open haydentherapper opened 1 month ago

haydentherapper commented 1 month ago

Is your feature request related to a problem? Please describe.

There is no support for offline verification currently. While a certificate is persisted in the DSSE signature, the Rekor entry proof is not, meaning the SLSA verifier must do an online lookup for the entry in Rekor.

Additionally, since all Sigstore clients now support the bundle format, this would allow SLSA clients to directly use Sigstore libraries to handle verification of the attestation signature (reducing code and simplifying maintenance), with the SLSA client handling verification of the attestation contents.

Describe the solution you'd like

Sigstore has defined a bundle format to store an attestation or signature along with verification metadata (certificate, signed timestamps, and Rekor log proofs). The generator should output a .sigstore.json bundle (the extension matches what other Sigstore clients output).

This was discussed in https://github.com/slsa-framework/slsa-github-generator/issues/716, but this issue was filed before the bundle format was created. This issue tracked persisting Rekor's inclusion proof as its own file.

Describe alternatives you've considered

An alternative would be to have a divergent format or save verification metadata as "detached" files, which complicates storage of that metadata for no benefit.

ramonpetgrave64 commented 1 month ago

The "BYOB" (bazel, maven, gradle, nodejs) builders will use the "delegator" workflows, which will use our .github/actions/sign-attestations action to produce Sigstore bundles.

The go builder and generic generator, still only produce the DSSE envelope.

If there were a go library for producing Sigstore bundles, then we could easily integrate it within existing code for producing attestation envelopes. But it seems only the sigstore-js library can do that.

Otherwise, I think we might be able to use reuse our existing .github/actions/generate-attestations and .github/actions/sign-attestations actions in the generic and go workflows.

ramonpetgrave64 commented 1 month ago

^ This could also make it easier to get all the generators to start using the SLSA v1.0 format for provenance, and simplify the slsa-verifier code significantly. cc : @laurentsimon @ianlewis

ianlewis commented 3 weeks ago

I agree we should try to move the generic generator and go builder to use BYOB code and internal actions. Ideally we could eventually remove the Go code to consolidate on TypeScript (and bash to a lesser extent). It would be a significant effort since it's essentially a rewrite but fairly straightforward.

I don't think we can really eliminate the Go code from the container-based (docker) builder that @asraa and @rbehjati worked on though. I don't know if anyone's using it or if we should properly support it.

ramonpetgrave64 commented 3 weeks ago

To give an update, sigstore-go now has bundle-producing functionality that I make use of in this PR to address this issue. I chose to modify the the original go code to produce Sigstore Bundles, instead of only DSSE envelopes, as a mostly drop-in replacement.

@ianlewis I also agree, but while attempting, I found that

ianlewis commented 2 weeks ago

Directly using our .github/actions/generate-attestations and .github/actions/sign-attestations actions in the original workflow requires a lot of careful and extensive manual testing.

Could you elaborate more on what you mean here? My understanding is that they currently expect to be a builder and thus generate a subject hash from the artifacts themselves, whereas for the generic generator we would need it to take the subject as an input. What kind of additional testing do you think would be required?

ramonpetgrave64 commented 2 weeks ago

@ianlewis I mean when I want to organize the actions, and their input and outputs. It took me a long while to demo a working conversion of the "generic-generator" that uses the "delegator".

I say it would be difficult to test because I think I would have to also include setup-generic and verfy-token in order to generate the SLSA_PREDICATE_FILE.

I hadn't tried it yet, so maybe it wouldn't have been so difficult. Github Actions workflows are generally not easy to debug, so I thought working with the go code would be a simpler to develop for.

ianlewis commented 1 week ago

Right. BYOB does need to be support generators. Should be a fairly straightforward conversion for the Go builder I think though.

ianlewis commented 1 week ago

Github Actions workflows are generally not easy to debug, so I thought working with the go code would be a simpler to develop for.

BTW, most of the TypeScript (aside from code that uses OIDC) should be able to be run locally if given the right environment variables and is similar to the Go code in that regard. Though not all of the actions are easy to invoke this way. I usually just set up some tests and run locally to debug before testing on GitHub Actions since the iteration loop is long there.