-
Notifications
You must be signed in to change notification settings - Fork 9
Create a new builder cmd to support new Docker-Based Builder type #145
Comments
@asraa Thanks for creating the issue and writing down the steps. With the new predicate format, I think we no longer need the first subcommand (
Our current builder already parses the config file, but does not support options, and environment variables. See transparent-release/internal/common/common.go Lines 78 to 90 in 8d11813
As a starting point, I suggest we remove the provenance generation from the current builder, and start from implementing the reusable GitHub workflow. Can you advise on how much of the functionality in https://github.com/slsa-framework/slsa-github-generator could be reused? We can then iterate on the parser and add support for options and environment variables. |
Sure! We can start from the skeleton of the workflow and move down. These are the components that can be reused: https://github.com/slsa-framework/slsa-github-generator/tree/main/.github/actions. They're around passing binaries between the VMs/jobs, checking out project repositories, and detecting the reusable workflows environment for the provenance. We can also re-use the signing packages that are used in the builders. We'd still need our own builder that can create the provenance and parse the udpated configuration.
I'm a tiny bit confused, just want to clarify. There still needs to be some translation from the inputs to the reusable workflow into the predicate that needs to be signed. Do you mean that instead we can create a "provenance generator" binary for the reusable workflow that does not overlap with the actual builder? If so, then I agree, but still think a binary or code needs to be written to package the inputs into the predicate |
Yes. I agree with that. It is just that with the new format the |
Summary of the discussion: We need three main components:
@asraa Please comment and correct me if anything is missing or incorrect :) |
That makes sense to me! We can follow-up on the predicate input command vs config. I've updated the issue with the two SLSA features (reusable workflow, builder binary), and we have a tracking milestone there too. |
@asraa Can we close this now that we have the container-based SLSA3 builder? |
Description
This is a meta/tracking issue to track AIs and dev items to support a SLSA 3 Docker-Based Builder according to
https://docs.google.com/document/d/1ky2yKk0dsSHuO6EjWyWtuyK4QupRD3eoBCzFpwzOWxc/edit?resourcekey=0-KyXXUyad6_XLpa_HPa7eYw#heading=h.x664rqu0e9bo (request access).
Steps and Timeline
Builder binary changes:
cmd/builder-alpha
or something else.generate-predicate
(which only resolves the--config
and produces the SLSA predicate). It also takes in the--docker-image
and--image-digest
and--output-path
. It may also take some GitHub context as input through the environment.build
command that may ingest the previously produced SLSA predicateThere are still some AIs to resolve, but I think (1) is possible to do now, as well as the scaffolding for the two builder commands.
Tracking issues:
@rbehjati
The text was updated successfully, but these errors were encountered: