Rename slsa2_provenance.yml

[ianlewis]

I think we can choose a scheme to name current and future workflows along the lines of builder_<ecosystem>_<slsa lvl>.yml.

For provenance only maybe we use something like generator_generic_slsa2.yml? Any other ideas?

[laurentsimon]

I was just about to create the same issue!

Since the generic provenance is not actually a "builder", more like a stamper...shall we think of a different name altogether?

Also, is the only reason it's not SLSA3 because we don't have the original command? Because aside from that, it ticks all the boxes for SLSA3. The building steps are missing, but everything else we report is non-forgeable.

@MarkLodato any thoughts on this?

[ianlewis]

I was just about to create the same issue!

Great minds...

Since the generic provenance is not actually a "builder", more like a stamper...shall we think of a different name altogether?

Yeah, that's why I suggested generator instead of builder.

Also, is the only reason it's not SLSA3 because we don't have the original command? Because aside from that, it ticks all the boxes for SLSA3. The building steps are missing, but everything else we report is non-forgeable.

My read before was that we don't technically support the Build as Code requirement because we don't verify anything about how the build was done. It says "configuration executed by the build service is verifiably derived from text file definitions stored in a version control system" in the description and we don't make any presumptions about this. Though we do include the workflow entrypoint so we do kind of assume that the user workflow is doing the build so maybe this is ok? 🤷
https://slsa.dev/spec/v0.1/requirements#build-as-code

I think for provenance-only we are kind of assuming that the build is done in the user's Github workflow and they aren't doing something like building it on their laptop and running the Github Actions workflow with the SHA as an input or something. I guess the fact that we aren't doing anything special to verify this is maybe the biggest sticking point for us at any SLSA level really.

[MarkLodato]

In my opinion, it does meet SLSA 3, pending the decision in slsa-framework/slsa#321. The build script is the workflow definition file, and the entry point is the path to that file.

[laurentsimon]

Makes sense to me. At SLSA3, someone can still build on their local machine and do curl local-machine-build. Hermeticity (which our SLSA3 Go builder enforces) prevents this to some extent. In general, hermeticity is not enough, because someone could commit the binary to the repo directly, or download the binary as part of the "dependency" download step, and rename it as part of the compilation step. Only builders that are language-aware and enforce certain constraints on the actual command can provide additional guarantees here - which our Go builder tries to do.

[laurentsimon]

I was just about to create the same issue!

Great minds...

Since the generic provenance is not actually a "builder", more like a stamper...shall we think of a different name altogether?

Yeah, that's why I suggested generator instead of builder.

+1, works for me.

[ianlewis]

I think it depends on how you think about it. I suppose it's true that we don't make it impossible to meet the SLSA 3 requirements in spirit, though I'm not sure we guarantee that the requirements are being met. So I guess the question is, how much is the provenance generator step responsible for actually ensuring that the requirements are being met? or is it enough to just not make achieving the requirements impossible?

For example, even with the Go runner we don't verify that the git history is all verified commits (Verified history).

For the former question, I'm not sure that there are even good ways for the slsa generator to validate some of the requirements, e.g. the retained indefinitely requirement, or review metadata for the two-person reviewed requirement.

So I think it may be fine for us to say "you can achieve SLSA 3 with these workflows (with some extra work)", even though you don't necessarily get SLSA3 just by using the workflows. This bit is a bit tricky and we don't want to mislead users.

[joshuagl]

Agreed that we don't want to mislead users. We could provide some additional guidance on what other things are required (i.e., list which GitHub configuration to enable and how to use AllStar to ensure the configuration is set) to meet SLSA L3 with the tools here. Aside; this would make a good topic for the SLSA blog.

However, if we make it clear that the generator and builders can be used to meet the Build and Provenance requirements only AND that the generated provenance MUST be verified to ensure it meets the requirements, then I think both can be labelled L3.

[laurentsimon]

Anyone wants to take a stab at a PR to adjust the README?

[joshuagl]

Sure, I'll make a PR.

[joshuagl]

Anyone wants to take a stab at a PR to adjust the README?

I created #199 to document which requirements the builders/generators here help folks achieve.
I'm working on a doc (blog post?) to describe e2e how to use the workflows here plus other tools & settings to meet all L3 requirements.

[laurentsimon]

I'm working on a doc (blog post?) to describe e2e how to use the workflows here plus other tools & settings to meet all L3 requirements.

Could be both, I guess. Blog post info will become out-of-date, so having in a doc in this repo seems necessary.

Fyi, several examples in https://github.com/slsa-framework/example-package/tree/main/.github/workflows, and script to verify is https://github.com/slsa-framework/example-package/blob/main/.github/workflows/scripts/e2e-verify.sh

[joshuagl]

+1, both it is.

[laurentsimon]

following up on the original question by @ianlewis and to unblock him on #172:

Shall we rename this "builder" to generator_generic_slsa3.yml or generator_generic_slsa2.yml?

I'm in favor of the former, given additional documentation proposed by @joshuagl

@MarkLodato @joshuagl final thoughts?

[joshuagl]

generator_generic_slsa3.yml seems reasonable to me.

[ianlewis]

SGTM