[discussion] [BYOB] Hosting multiple builders in the same repository

[aalmiray]

As you may be aware, JReleaser provided a BYOB at the time of the feature's launch (blog). This builder is capable of generating SLSA provenance for any Java based build, whether it's Apache Maven, Apache, Ant, Gradle, etc.

AFAICT the current implementation of the BYOB feature expects TRWs to run on a single node (Linux atm). This limits the use of builders for projects that require multiple nodes (think cross-compilation). However, this is not a problem for languages that do provide cross-compilation on a single platform such as Go, Zig, Rust, and others.

For this reason, I've added more builders to JReleaser such that the following are now available:

• Java
• Go
• Zig
• Rust

Examples at:

https://github.com/aalmiray/helloworld-java-slsa
https://github.com/aalmiray/helloworld-go-slsa
https://github.com/aalmiray/helloworld-zig-slsa
https://github.com/aalmiray/helloworld-rustzig-slsa

Each of these builders lives in its own branch, having separate release cycles and tags. There is however, lots of duplication in the code and now I wonder if the SLSA framework imposes any restrictions when resolving TRWs. Ideally all builders could be hosted on the same branch while still having their own release cycles and tags, allowing for

 * jreleaser/release-action/.github/workflows/[email protected]
 * jreleaser/release-action/.github/workflows/[email protected]
 * jreleaser/release-action/.github/workflows/[email protected]
 * jreleaser/release-action/.github/workflows/[email protected]

[mlieberman85]

Excuse my ignorance here but what does TRW stand for here?

[aalmiray]

I believe it stands for Trusted Reusable Workflow.

[mlieberman85]

Makes sense! I don't think there's anything that should restrict it to have to be in separate repos or branches? If there is then it's definitely an in the BYOB process.

[aalmiray]

Well the one reason I can think of having such restriction in place is to ensure stability and authenticity of a given TRW. And if there were to be a naming conventions in place, as the Java builder currently uses a tag format such as v1.2.3-java instead of the usual v1.2.3.

The BYOB infra was updated to handle such tag, and thus there's a naming/format convention to be followed. Of course, all these BYOBs could revert to just using v1.2.3 instead of v1.2.3-lang.

[mlieberman85]

Based on semantic versioning parsing stuff that always causes headaches I would prefer the first over the second. With that said it's not a big deal one way or another. I might be misunderstanding through. Shouldn't something like:

jreleaser/release-action/.github/workflows/[email protected]
and jreleaser/release-action/.github/workflows/[email protected] be good enough?

[aalmiray]

That is my thinking. I believe the decision was made early on for the JReleaser builder to have a tag alongside the version to make quite clear which language was the target. Of course that could also be done with the workflow name.

[mlieberman85]

I wonder if other folks like @TomHennen, @ianlewis, @steiza, etc. have thoughts here?

[steiza]

Admittedly, I'm not super-familiar with the BYOB parts of SLSA. But I think this comes down to a question of verification - can your verification support multiple workflows in the same repository (which I think is what you want), or does your verification require the workflow to always be the same (which you're accomplishing today with multiple branches, which is a pain to maintain).

How are you expecting folks to verify these attestations? I'm in favor of verification tooling supporting regular expressions, like how cosign verify blob-attestation supports --certificate-identity-regexp, or how sigstore-go supports --expectedSANRegex. Then, with those tools, you could supply something like https://github.com/jreleaser/release-action/.github/workflows/builder_slsa3_*.

[aalmiray]

I expect verification to occur using https://github.com/slsa-framework/slsa-verifier

I'm unaware of any constraints imposed by the verifcation mechanism, hence why I raised this question.

[ianlewis]

Verification should be ok since we have use the full repository and workflow path in the builder ID. I believe this issue is mostly regarding the fact that you have multiple workflows you would like to version separately but need to share the same set of tags by virtue of being in the same repository.

And this issue is most acute since dependency management systems like dependabot look for these tags in semantic version format. So it's a limitation of git and GitHub Actions.

[ianlewis]

Verification should be ok since we have use the full repository and workflow path in the builder ID

Note that we do this in the slsa-github-generator repository. All of the workflows here are managed with the same set of tags and have the same release cycle so it's not ideal from a release management point of view, but simplifies things by having one repo.

[aalmiray]

OK. I gather I can host all builders in the same branch without causing issues with verification. Renaming the builder workflow by appending the target language will make the tag semver compliant as there's no need to have the suffix in the tag.

Now that a year has passed since BYOB's launch I suppose builders could move to the main branch. However there's a chicken-egg problem as builders should refer to the core action using a hash. Main should be released and tagged before builders. I guess keeping all builders in a separate branch other than main will be the way to go.

One issue remains: use the same tag for all builders. I guess the is is more of a preference and not a limitation imposed by the BYOB infrastructure.

[mlieberman85]

Yeah, that chicken-egg problem is an annoying one and doesn't just impact the BYOB but anything that relies on referencing the same repo. I think that one is just a tradeoff on relying on the circular nature of the github actions being in a git repo that also references things in that same git repo.

Ideally github would have a mechanic for releasing github actions similar to other artifacts and allow referencing that way.

[TomHennen]

FWIW hosting multiple builders in the same repo seems fine with me (and I'm glad @ianlewis confirms it should 'just work').

[aalmiray]

Thank you for your answers. I just realized another thing: the core action and builders can't share the same tags when they are hosted on the same repo, given the core action has to be released before builders can consume it.

IIRC @laurentsimon suggested that the JReleaser builders should be hosted at the same repo as the core action to make verification easier. However, the Maven and Gradle builders (https://github.com/slsa-framework/slsa-github-generator/tree/main/internal/builders) are hosted at a repo whose language/tool specific action is hosted somewhere else.

I wonder if it would make sense to split the JReleaser core action and the SLSA builders in two repos. Would there be any drawbacks wrt provenance generation & verification?

[mlieberman85]

Nothing comes to mind. It seems reasonable to do it either way.