Reduce action runtime

[joshuagl]

I have projects which take about ~30s to build where adding the provenance only workflow to those projects significantly increases build time because building slsa-github-generator takes >2min.

It would be good to reduce build time, or otherwise decrease the runtime of the action, before encouraging wider adoption.

[laurentsimon]

Thanks for raising this problem. A quick look at the e2e integration tests (https://github.com/slsa-framework/example-package/actions/runs/2357668677) show that building the builder takes 2mn, while other VMs finish in a few seconds. Numbers from the link above:

• 26s to download dependencies
• 1.42mn to compile

I added some logging and re-ran the re-usable workflow:

• Dependency download: ~30s
• Builder's build: ~1.30mn
• Builder's binary upload: ~5s

1. Use a container image + provenance for it (do-able using the ko trusted builder, but requires ko to be ready)
2. Use a container image + sign the image using cosign (as a step towards previous option)
3. Use a Dockerfile for the action, and pull the builder binary from the GH release assets and verify its provenance before using it.
4. Pull the binary + provenance from the GH release and use it
5. Dont do any of the above if the build is reproducible (?) Unlikely and harder for someone to verify

There's a bit of a chicken-and-egg problem to solve for each option. But there's probably a way to solve that. Also note that verifying provenance requires the slsa-verifier, which will take the same amount of time to build, so we'll also need to pull the binary from a release

Thoughts?

[laurentsimon]

I'm working on this. TL;DR:

1. I'll introduce a new workflow option compile-builder which will optionally build the builder from source. By default it will be false. We need not advertise this option.
2. For releases of this repo and the slsa-verifier repo, we'll always build from source
3. When users build, they will mostly use the pre-built builder. So the re-usable workflow code will roughly do:
   3.1 Resolve the @hash to a version/tag (for v1 we're not going to support hash but the code will be there anyway)
   3.2 Given a version (@v1.2.3 or resolved from previous point), we will download the builder's binary and provenance
   3.3. We will download slsa-verifier from release and verify its hash with a hardcoded value
   3.4. We will use the slsa-verifier's binary to verify the provenance of the builder (commit hash, tag, source)
4. We will run the builder

Note: for the verifier, we need a hash since the verifier cannot verify itself, i.e. it's untrusted upon download. So we will keep a list of good hashes in the verifier's repo. After a release, I will create a PR with a mapping between a release binary and a release tag. Other maintainers will verify the hash of this binary is correct by:

1. Verify that the workflow used to generate the release has the option compile-builder set to true
2. Locally download the untrusted verifier binary from the release assets
3. sha256sum this untrusted binary
4. Clone the verifier source code locally (trusted, since it has code reviews turned on)
5. Build the verifier as trusted-verifier
6. Run the trusted-verifier on the verifier binary downloaded in step 1
7. LGTM the PR

We can build a little utility later to simplify this.

[laurentsimon]

See #86 and slsa-framework/slsa-verifier#63

Once they are merged:

1. I'll cut a v0.0.1 release for the builder
2. I'll cut a v0.0.1 for the verifier, using the v0.0.1's builder release
3. We-ll update the verifier hash as described in previous comment
4. We'll update the hash https://github.com/laurentsimon/slsa-github-generator/blob/feat/fastbuilds/.github/workflows/builder_go_slsa3.yml#L30

From there we can update the hash/tag of the verifier when we need to.

[laurentsimon]

going to cut a v0.0.1 release to test the entire flow. The verifier will only accept reusable workflows pinned by tag (not by @main). The builder supports pinning by hash, but not the verifier yet. We can do that later - see discussion in slsa-framework/slsa-verifier#12

[laurentsimon]

@joshuagl can you check the new builder @v0.0.2 and tell me if the build is faster? The builder's binary is pulled from the release assets; it takes ~20s instead of ~2mn. However the overall build will still take longer depending on VM scheduling.

[ianlewis]

I think we can close this for the Go builder?

[laurentsimon]

This is done. Closing