[Proposal] add provenance document creation support based on in-toto attestations

[developer-guy]

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

Describe the solution you'd like

Attestations are more like a document/record to give details about how the software was built. in-toto provides/defines very detailed documents for it, so, GoReleaser can generate software provenance documents based on in-toto attestations IMHO.

Tekton Chains is also creating this document based on its format.

Additional context

• https://shibumi.dev/posts/introduction-to-in-toto/
• https://blog.acolyer.org/2019/10/02/in-toto/
• https://github.com/in-toto/in-toto-golang

cc: @dlorenc @caarlos0 @Dentrax @adityasaky @SantiagoTorres

[developer-guy]

maybe we can approach this issue from a different angle, we can use slsa-provenance CLI from philips-labs to generate an SLSA provenance, then we can sign and attach it using cosign under the hood instead of generating it our own in GoReleaser.

or we can use this: slsa-framework/github-actions-demo

cc: @marcofranssen @shibumi @Dentrax

[caarlos0]

I think we can experiment running the action before running goreleaser, then just adding the file to the release and signing it

[caarlos0]

scratch that, it needs to run after... so, not sure if we use the action directly or integrate it more properly with goreleaser

maybe its possible to use the signs config for it? 🤔

[SantiagoTorres]

I think the slsa-provenance type could work (it's still an in-toto type). Let me know if there is anything I can help w/ it

[marcofranssen]

Happy to have a chat on how we can integrate slsa-provenance with goreleaser.

We are using goreleaser as well for releasing the slsa-provenance-action. "chicken and egg" problem to release our own thing with goreleaser, once the provenance feature is added.

[caarlos0]

hey @marcofranssen , feel free to ping me on our discord! https://discord.gg/RGEBtg8vQ6

[caarlos0]

is there someone interested in working on this?

[developer-guy]

There is also another project that can help us. It generates an attestation (based on SLSA) and stores it in a Rekor public transparency log server provided by the sigstore community.

＞ https://github.com/slsa-framework/slsa-github-generator-go

[developer-guy]

@Dentrax, let's give it a try?

[developer-guy]

ping @Dentrax

[developer-guy]

helpful links:

• https://github.com/marcofranssen/slsa-workflow-examples
• https://marcofranssen.nl/secure-your-software-supply-chain-using-sigstore-and-github-actions

[developer-guy]

I'd like to propose the same UX that was being proposed by @wagoodman in his Syft integration to GoReleaser (#2597)

# .goreleaser.yml
provenances:
  -
    # ID of the provenance config, must be unique.
    #
    # Defaults to "default".
    id: foo

    # List of Names/templates of the provenance files created at this step.
    #
    # Available environment variables:
    # - '${artifact}': the path to the artifact that will be provenance generated
    # - '${artifactID}': the ID of the artifact that will be provenance generated
    #
    # Defaults to empty list.
    provenance: 
      - "${artifact}.att"

    # Path to the provenance generator command
    # Source: https://github.com/philips-labs/slsa-provenance-action/releases   
    cmd: slsa-provenance

    # Command line templateable arguments for the command
    # we should supply these also: --digest "${IMAGE_DIGEST}" --tags "${IMAGE_TAGS}
    args: ["generate", "container", "--output-path", "${provenance}", --repository "${artifact}"]

    # Which artifacts to generate provenance
    #
    #   binary:   binaries output from the build stage
    #   container:  reference to the published container image 
    #... there maybe other artifacts that make sense here!
    #
    # Defaults to `container`
    artifacts: container

    # Which environment variables will be supplied to the command
    env:
      - FOO=bar
      - HONK=honkhonk

cc: @marcofranssen @caarlos0

[caarlos0]

@developer-guy lgtm!

[asraa]

@developer-guy @caarlos0

cc @laurentsimon

Hey! As mentioned before, we've been creating trusted builders using reuseable workflows to generate slsa provenance. for golang, we modeled our config after goreleaser. The reusable workflow guarantees isolation from the calling workflow (the projects) maintainer's from interfering with the build and provenance generation, something unique to reuseable workflows over actions because env variables and defaults don't propogate to them.

I'm wondering if it's possible to support a goreleaser "reuseable workflow" that can use the same goreleaser binary and config, but guarantees a strong isolation over an action.

Taking a look at https://github.com/slsa-framework/slsa-github-generator/blob/675472104f54a100560e96e8090921390a77cadf/.github/workflows/builder_go_slsa3.yml#L84-L88, the steps of our builder does:

1. Build the builder
2. Dry run of the build to resolve variables to use in provenance generation (command, binary name, environment vars, working dir)
3. Build
4. Upload the generated binaries
5. Generate & sign SLSA provenance
6. Upload assets if needed

If goreleaser supports a dry run for the build, then we could directly substitute the goreleaser build. There may be some flags and environment vars goreleaser may allow that we don't currently allow, but TBD

[developer-guy]

I thought that GoReleaser could use these SLSA provenance generators that were out there, such as slsa-framework/slsa-github-generator, philips-labs/slsa-provenance-action, but @asraa gave another idea, and she tell us that IIUC, we could make GoReleaser is a part of its provenance generator for building binaries, that is so interesting, and we should discuss on that @caarlos0

[caarlos0]

yes, tbh I'm not well versed in all that and don't know how most of it works, so maybe we could chat about it on discord or something (or here too, wherever you prefer 🙏)

[laurentsimon]

Please keep me in the loop as well. I work with @asraa on slsa-framework/slsa-github-generator.

[caarlos0]

@laurentsimon will probably keep posting here and/or in our discord

[Dentrax]

Has anybody started work on this yet? Maybe we can integrate the slsa-github-generator as a lib.

[caarlos0]

I don't think anyone is working on it, no, wanna give it a try?

[asraa]

Has anybody started work on this yet? Maybe we can integrate the slsa-github-generator as a lib.

Hey! Recently @laurentsimon and I have been working on creating an "action wrapper" that reaches SLSA 3, and we thought of GoReleaser Action as the perfect candidate for that.

We are targetting the next quarter or two for GA of it -- it may make sense @Dentrax to integrate with this. If you're interested, we can share how to do that! (It's a lot more lightweight than reconstructing libraries or coding. Just workflow templating)

[laurentsimon]

We can showcase a demo in a few weeks. What's the best way to get in touch? slack?

[caarlos0]

We can showcase a demo in a few weeks. What's the best way to get in touch? slack?

I'm on discord, I think @Dentrax is too.

https://goreleaser.com/discord

[developer-guy]

count me in !

[asraa]

hey! we are one step closer. I have a "POC" that performs a goreleaser build and creates Sigstore signed SLSA 3 provenance.

There's obvious missing parts that I didn't do yet:

• Piping all the possible goreleaser args through the workflow (it's hardcoded with release)
• Accessing the default github token to actually create the release
• Attestation to all the subjects produced (I only did the first)
• Call goreleaser action locally instead of pinned at a version here

Here's the test run: https://github.com/asraa/slsa-on-github-test/actions/runs/4017434808 producing the goreleaser artifacts in goreleaser and the attestations in slsa-attestations-*. I'm cleaning this up as we go.

Here is the SLSA 3 goreleaser workflow (that wraps the action): https://github.com/asraa/slsa-on-github/blob/main/.github/workflows/goreleaser_slsa3.yml

Let's chat! I'll definitely need some help writing docs, testing, making examples.

[laurentsimon]

Here's another PoC for anchor sbom-action (the reusable workflow are just copied from @asraa 's example):
https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/.github/workflows/slsa3.yml
https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/internal/sbom-wrapper/action.yml

You can define arguments inputs (mirroring the original Action):
https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/.github/workflows/slsa3.yml#L11-L113

and pass it to the original Action:
https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/internal/sbom-wrapper/action.yml#L36-L49

[caarlos0]

gently pint: what's the state of this one?

[laurentsimon]

We have done an integration for jreleaser, see https://slsa.dev/blog/2023/08/bring-your-own-builder-github and https://github.com/jreleaser/release-action/tree/v1.1.0-java.
We're happy to help you integrate, unless you prefer keeping only this option https://goreleaser.com/blog/slsa-generation-for-your-artifacts/
/cc @aalmiray

[caarlos0]

hey @laurentsimon

Yeah, seems like jreleaser's slsa integration is easier to use than the example from that blog post... I think it would be nice to do something similar...

cc/ @developer-guy wdyt?

[laurentsimon]

Note that are are also security considerations:

1. Using BYOB, we can technically record all dependencies in the attestation, reaching L4 level. We don't support it yet but it's a feature we can add in the future
2. The blog post https://goreleaser.com/blog/slsa-generation-for-your-artifacts/ uses the generic generator, which is only able to attest to the workflow+inputs used by the build, but not the exact runner. On the contrary, BYOB (like our own Go builder) can attest to the runner to avoid situations like https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/. That's simply because in BYOB we control the runner where the build run, so we can ensure it's GitHub-hosted

[developer-guy]

great resources, thanks for sharing!

[laurentsimon]

np. To be fair on the runner, we have slsa-framework/slsa-github-generator#1868 which may fix it :)

[laurentsimon]

Will any of you attend KubeCon Paris?

[laurentsimon]

ouch, I did not see the thumb up :/ Anyone attending OSS@NA?

[adityasaky]

I'll be there, as will some other in-toto/attestation folks.