[feature] Make all builders use .build-slsa extension

[laurentsimon]

No description provided.

[ianlewis]

I kind of wonder if this is really the right approach. Not many file extensions refer to the intended use of the file as opposed to the format. e.g. .jpg or .png as opposed to .img.

So I think this may be fairly counter-intuitive for users.

[ianlewis]

For BYOB, which produces Sigstore bundles, I'm wondering if .sigstore.json wouldn't be the most descriptive. Sigstore bundles don't seem to have a specific file extension and they could technically come in multiple formats (.json, .binpb, or .txtpb) since it's defined in protobuf.

[haydentherapper]

@ianlewis, did you have a code pointer to where bundles are generated in slsa-github-generator? I was just poking around this.

Other Sigstore clients are using .sigstore.json as the extension for a sigstore bundle which wraps provenance (or an artifact hash).

[haydentherapper]

Just filed #3750 to track bundle output.

[ianlewis]

@ianlewis, did you have a code pointer to where bundles are generated in slsa-github-generator? I was just poking around this.

Other Sigstore clients are using .sigstore.json as the extension for a sigstore bundle which wraps provenance (or an artifact hash).

In BYOB builders, for better or worse, the generation of provenance is a multi-step process.

1. setup-generic generates a token in the context of the caller "Tool Reusable Workflow" (TRW) to get info from the callers context. This is signed with sigstore so it can be verified later.
2. The token is verified by the BYOB workflow with verify-token and this generates a SLSA predicate.
3. generate-attestations generates an unsigned provenance for each set of artifacts requested by the caller TRW's "Tool Callback Action" (TCA).
4. sign-attestations takes the resulting provenance and signs it, creating the resulting sigstore bundles with the sigstore.js client.

For pre-BYOB builders we generate DSSE wrapped SLSA provenance as .intoto.jsonl files. These aren't sigstore bundles but are signed using sigstore with code in the signing package.

[haydentherapper]

Thanks for the pointers!

I would suggest we pursue Sigstore bundles in #3750 as that gives us an easy way to bundle DSSEs with the necessary verification material for offline verification (cert and log proof).

If we do want DSSEs as the outer envelope, we had also explored adding custom extensions to DSSE (secure-systems-lab/dsse#61) where you could specify an ecosystem-defined struct. This would be similar to the addition of the cert in the signature, except it could contain all of the rest of the Sigstore verification material. But there isn't much tooling support for this currently.

[ianlewis]

Sounds good to me. From a purity standpoint I wish we could not fully rely on a Sigstore format as we'd also like to support private PKI at some point (#34) but creating sigstore bundles by default seems best for offline verification purposes.

To be clear though, this issue is around the file extension rather than the format itself. @laurentsimon had argued to use the .build.slsa extension regardless of file format (sigstore bundle, dsse, whatever), and let verifiers sort it out so that there was a common file name to look for provenance and it puts less burden on the end user. I'm leaning more towards having the file extension just reflect the file format per my earlier comments.

[haydentherapper]

I'll mention that the Sigstore bundle should work for private PKI as well. We've designed it to primarily support the spec-compliant path but it's decently flexible - timestamps aren't required, proofs aren't required, you can put certificates, cert chains, or public key identifiers.

[ianlewis]

I'll mention that the Sigstore bundle should work for private PKI as well. We've designed it to primarily support the spec-compliant path but it's decently flexible - timestamps aren't required, proofs aren't required, you can put certificates, cert chains, or public key identifiers.

Good to know.