search

slsa-framework / slsa-github-generator

Language-agnostic SLSA provenance generation for Github Actions
Apache License 2.0
412 stars 127 forks source link

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

Open laurentsimon opened 8 months ago

ianlewis commented 3 months ago

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 commented 3 months ago

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 commented 1 month ago

@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 commented 1 month ago

Just filed https://github.com/slsa-framework/slsa-github-generator/issues/3750 to track bundle output.

ianlewis commented 2 weeks ago

@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 commented 1 week ago

Thanks for the pointers!

I would suggest we pursue Sigstore bundles in https://github.com/slsa-framework/slsa-github-generator/issues/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 (https://github.com/secure-systems-lab/dsse/pull/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 commented 1 week ago

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 commented 4 days ago

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 commented 3 days ago

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.