[feature] Use go code within the builder_go_slsa3.yml

[naveensrinivasan]

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

slsa-github-generator/.github/workflows/builder_go_slsa3.yml

Line 15 in 024238b

name: SLSA go builder

has lots of shell script which is harder to maintain and harder to debug

Describe the solution you'd like

Use go code instead of using shell script. Another option is to use something like https://github.com/magefile/mage for doing this. Also mage has 0 dependencies.

[ianlewis]

I'd prefer not to use bash where it makes sense as well. I think the main issue with this is that we have to compile and run the code each run, it pretty hard for small snippets and increases the build times since Go compilation time isn't trivial. We've needed to reduce run time for #74 before.

I'm not totally sure about the builder workflows themselves but it might make sense for us to rewrite some of our e2e tests in Go since much more extensive bash.

[laurentsimon]

+1 to what @ianlewis said.

Go can be an option when there are few dependencies (also good for maintenance and attack surface reduction). We use Go for the detect action https://github.com/slsa-framework/slsa-github-generator/tree/main/.github/actions/detect-workflow, and it seems to be fast enough.

We have #87, #132 and #26 that are related.

We should be able to reduce code duplication with #26. The code for building/verifying artifact after download (sha256sum command) is duplicated in the Go and generic workflow. And we could possibly use typescript, which requires no compilation and is fast for GH actions.

I suspect we'll still need a little bit of scripts, especially when we use composite GH actions to perform multiple steps at once.

[ianlewis]

Yeah, it's a balance between

1. complexity - number of programming languages, libraries, coding styles etc.
2. reusability - ability to reuse code across actions/workflows
3. performance - need to compile, speed of action/workflow execution
4. security - attack surface, # and severity of potential bugs

As @laurentsimon said, I think the solution will not necessarily be just porting the existing scripts to Go but mostly creating reusable actions that are written in another language. That way it strikes a better balance with the concerns above. If we have that we can maybe just small snippets of bash and minimize the amount of code that we have to maintain.

[ianlewis]

Adding comments from PR #503
#503 (comment)

@naveensrinivasan
After thinking about this should probably be written in go. This is adding tech debt.

@ianlewis
Yeah, I'd like to reduce our use of inline shell scripts if we can too. Though it's pretty small so I could go either way.
I think installing Go compiler and compiling the program will add too much overhead to these kind of small actions. And we also really want to avoid having to do a checkout of the repository as part of the action as there are version skew and security implications.
If we want to write them in another language I think the best choice would probably be writing it in Javascript. It works similarly to the Dockerfile actions, but doesn't require building the image every time before running it.

@laurentsimon
I'm also leaning towards TS. On the other hand, the script is really small. I'm not even sure I'd call it "tech debt".

[laurentsimon]

The workflows now use common actions, so I think we can close this issue. Please re-open if needed. Thanks