feat: generate SLSA provenance for release binaries #730

laurentsimon · 2022-06-14T19:28:59Z

Generate non-forgeable provenance, as proposed in #729

Below is an example of what the provenance looks like:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "ko-copy_5.0.1_Windows_arm64.tar.gz",
      "digest": {
        "sha256": "01a6a93df134ff638c7da1ccdd735398a979cb08c9d103e64d3a22f29e23223b"
      }
    },
    {
      "name": "ko-copy_5.0.1_Linux_i386.tar.gz",
      "digest": {
        "sha256": "520bcf95c284d0e9c43f02ae516f7ad35d26a24d9103d49e5977ed9a94511017"
      }
    },
    ...
  ],
  "predicate": {
    "builder": {
      "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@refs/tags/v1.0.0"
    },
    "buildType": "https://github.com/slsa-framework/slsa-github-generator@v1",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/google/ko@refs/tags/v0.0.4",
        "digest": {
          "sha1": "b6e9b26f5c8af4fbcb880f14ac9ad961a2b84e43"
        },
        "entryPoint": ".github/workflows/slsa-release.yml"
      },
      "parameters": {},
      "environment": {
        "arch": "X64",
        "github_actor": "laurentsimon",
        "github_actor_id": "64505099",
        "github_base_ref": "",
        "github_event_name": "push",
        "github_event_payload": {...},
        "github_head_ref": "",
        "github_ref": "refs/tags/v0.0.4",
        "github_ref_type": "tag",
        "github_repository_id": "501698356",
        "github_repository_owner": "laurentsimon",
        "github_repository_owner_id": "64505099",
        "github_run_attempt": "1",
        "github_run_id": "2497311143",
        "github_run_number": "4",
        "github_sha1": "b6e9b26f5c8af4fbcb880f14ac9ad961a2b84e43",
        "os": "ubuntu20"
      }
    },
    "buildConfig": nil,
    "metadata": {
      "buildInvocationID": "2497311143-1",
      "completeness": {
        "parameters": true,
        "environment": false,
        "materials": false
      },
      "reproducible": false
    },
    "materials": [
      {
        "uri": "git+https://github.com/google/ko@refs/tags/v0.0.4",
        "digest": {
          "sha1": "b6e9b26f5c8af4fbcb880f14ac9ad961a2b84e43"
        }
      },
      {
        "uri": "https://github.com/actions/virtual-environments/releases/tag/ubuntu20/20220605.1"
      }
    ]
  }
}

imjasonh

Cool! Always happy to test out better supply chain security workflows 😎

.github/workflows/slsa-goreleaser.yml

imjasonh · 2022-06-14T19:50:10Z

README.md

-ARCH=x86_64  # or arm64, i386, s390x
-curl -L https://github.com/google/ko/releases/download/v${VERSION}/ko_${VERSION}_${OS}_${ARCH}.tar.gz | tar xzf - ko
-chmod +x ./ko
+We are one of the first repositories to generate SLSA3+ provenance using the OpenSSF's [slsa-framework/slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) project.


This comment will (hopefully) fall out of date pretty fast. Can we just say, "here's how to install a release", and then later, "here's how to verify the released artifact"? The verifying-the-release section may even make more sense lower in the README, since folks who already have ko installed may not want to scroll past it.

(Longer term I'd love to not have one big README and instead have a real website with docs and tutorials and everything, but until then...)

I've made some changes. Can you take a look and tell me what you think?

laurentsimon · 2022-06-14T20:13:06Z

Cool! Always happy to test out better supply chain security workflows 😎

Awesome, thanks!

imjasonh · 2022-06-14T20:26:34Z

.slsa-goreleaser.yml

@@ -0,0 +1,13 @@
+version: 1


Does this need to be its own file? I'm worried about this diverging from goreleaser eventually.

Or, if the idea is to eventually only have the SLSA-flavored goreleaser workflow, I wonder if you've considered just adding the SLSA provenance functionality to goreleaser proper, and not having your own fork?

Does this need to be its own file? I'm worried about this diverging from goreleaser eventually.

right now it needs to be its own file, yes.

Or, if the idea is to eventually only have the SLSA-flavored goreleaser workflow,

correct. In the next release we will support multiple builds, so we should be able to migrate the rest of the config.

I wonder if you've considered just adding the SLSA provenance functionality to goreleaser proper, and not having your own fork?

We have (see goreleaser/goreleaser#2737) and we emailed them, but no concrete plan yet :/

It sounds like there's still some discussion happening on goreleaser/goreleaser#2737, and I'd kind of like that to land somewhere before proceeding to fork the release process here. If you need any help getting the SLSA provenance generation landed in goreleaser, let me know.

I'd rather not have a forked release process per-target-arch, and long term, I'd prefer to rely on the standard upstream goreleaser if at all possible.

It sounds like there's still some discussion happening on goreleaser/goreleaser#2737, and I'd kind of like that to land somewhere before proceeding to fork the release process here. If you need any help getting the SLSA provenance generation landed in goreleaser, let me know.

Would love your help. Much appreciated, thanks!

I'd rather not have a forked release process per-target-arch, and long term, I'd prefer to rely on the standard upstream goreleaser if at all possible.

Any particular reason? We'd like to learn about blockers to adoption to improve our solution. Feedback welcome!

Multi-build support will be added next quarter.

It's mainly just for consistency among our released artifacts. The x86_64 binary is definitely the most used, and if behavior continues to diverge between them I don't want the minority of users to have different behavior. Ideally goreleaser would pick up these improvements (rooting for #2737!) and all our released binaries would immediately and consistently get better.

SG. What if we land multi-build support in v2? Would that alleviate the problem? I'd like to know what the minimum requirements would be, so that we can target them for our v2 release.

Thanks again for you help and feedback!

I'm not sure I understand what multi-build support entails, or v2 of what project. In my ideal scenario, goreleaser would be able to be configured to generate and attach attestation documents to releases, which users could use to verify the provenance of each goreleaser-built artifact.

Ideally that's done by just adding generate-attestations: true in the goreleaser.yaml somewhere, and no new dependencies on other projects.

Sorry for the confusion. What I mean is that in the next release of our SLSA builder, we will support building for multiple arch/os at once, like Goreleaser does. So it would be easy to migrate to our builder instead of Goreleaser with a similar config file.

Ideally that's done by just adding generate-attestations: true in the goreleaser.yaml somewhere, and no new dependencies on other projects.

I'd like to understand better the requirement to use Goreleaser.

Any update on #2737?

.github/workflows/slsa-goreleaser.yml

laurentsimon · 2022-06-15T21:58:39Z

Any further concern I should address?

laurentsimon · 2022-07-25T19:20:14Z

I've updated the PR:

Keep the current GoReleaser config
Add a call to the SLSA generator to create provenance using the output of GoReleaser. The provenance file attests that the build was created in the release.yaml workflow, at a particular commit.

A follow-up PR would be to verify the binary pulled in https://github.com/imjasonh/setup-ko/blob/main/action.yml#L41. We're still working on a GHA installer for the verifier, so that is not ready yet :)

Appreciate your feedback. Thanks again

laurentsimon · 2022-07-25T20:11:40Z

.github/workflows/release.yml

+      contents: write # To add assets to a release.
+    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.2.0
+    with:
+      base64-subjects: "${{ needs.goreleaser.outputs.hashes }}"


note: this will create an attestation file attestation.intoto.jsonl by default. The name can be customized with the option: attestation-name: xxx.intoto.jsonl if you want.

laurentsimon · 2022-07-26T20:45:34Z

Fyi, this PR is ready to be reviewed.
Let me know if you have questions. Thanks!

imjasonh · 2022-07-27T19:11:14Z

Fyi, this PR is ready to be reviewed. Let me know if you have questions. Thanks!

I probably won't have the bandwidth to review this closely for at least a week or so. I'm excited to see this progressing though, and especially now that it seems to require fewer changes to the release process. Thanks for pushing on that! 👍

laurentsimon · 2022-08-09T17:14:48Z

Friendly ping. Would love to hear your feedback. Thanks again.

imjasonh · 2022-08-09T18:04:33Z

This looks pretty good to me. Would it be possible to have the release workflow also attempt to verify it, so we can detect quickly if verification is silently broken due to some future change?

@jonjohnsonjr any concerns?

codecov-commenter · 2022-08-09T18:05:17Z

Codecov Report

Merging #730 (4a4897b) into main (7fafb61) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #730   +/-   ##
=======================================
  Coverage   51.40%   51.40%           
=======================================
  Files          44       44           
  Lines        3336     3336           
=======================================
  Hits         1715     1715           
  Misses       1403     1403           
  Partials      218      218

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

laurentsimon · 2022-08-09T19:06:59Z

This looks pretty good to me. Would it be possible to have the release workflow also attempt to verify it, so we can detect quickly if verification is silently broken due to some future change?

I can do that. How to you typically create the tag? Via a git command or via the GitHub UX?

@jonjohnsonjr any concerns?

imjasonh · 2022-08-09T19:52:41Z

I usually do it through the UI, but I think triggering based on new tags should catch both cases.

laurentsimon · 2022-08-11T01:17:30Z

I have added the verification job. PTAL.

laurentsimon · 2022-08-16T21:59:32Z

@imjasonh any other feedback you'd like me to address?

developer-guy · 2023-09-07T11:55:07Z

As we completed the SLSA provenance generation for release binaries, should we move on with the same for ko images? @imjasonh ^^

laurentsimon mentioned this pull request Jun 14, 2022

Generate SLSA provenance for your release builds #729

Closed

imjasonh reviewed Jun 14, 2022

View reviewed changes

imjasonh mentioned this pull request Jul 7, 2022

chore: slsa 3 provenance generation #753

Closed

laurentsimon added 9 commits July 25, 2022 19:14

Support for SLSA provenance generation

5d28ecc

updates

60098b0

updates

8fa30c2

updates

bfe600c

updates

af9ae56

updates

f6a984f

comment

6059d03

update

838bd31

update

fbd1ed1

laurentsimon force-pushed the feat/slsa3 branch from 013a123 to fbd1ed1 Compare July 25, 2022 19:14

laurentsimon changed the title ~~✨ Generate SLSA provenance for Linux-x86_64 build~~ Generate SLSA provenance for Linux-x86_64 build Jul 25, 2022

laurentsimon added 2 commits July 25, 2022 19:15

update

17d55af

update

563a98e

laurentsimon changed the title ~~Generate SLSA provenance for Linux-x86_64 build~~ Generate SLSA provenance for release binaries Jul 25, 2022

laurentsimon commented Jul 25, 2022

View reviewed changes

update

ff9e28a

laurentsimon changed the title ~~Generate SLSA provenance for release binaries~~ feat: fenerate SLSA provenance for release binaries Jul 28, 2022

This was referenced Aug 10, 2022

Action to install/run the verifier slsa-framework/slsa-verifier#95

Closed

Generate SLSA provenance for binaries in GitHub releases docker/buildx#1243

Open

update

822d8fb

laurentsimon added 3 commits August 11, 2022 01:18

update

d1c801b

update

a5955a5

update

4a4897b

imjasonh changed the title ~~feat: fenerate SLSA provenance for release binaries~~ feat: generate SLSA provenance for release binaries Aug 16, 2022

imjasonh approved these changes Aug 16, 2022

View reviewed changes

imjasonh merged commit 14b4fe1 into ko-build:main Aug 16, 2022

imjasonh mentioned this pull request Aug 19, 2022

feat: sign checksum using cosign #498

Closed

developer-guy mentioned this pull request Aug 24, 2022

SLSA Level 3 compliance for Kyverno kyverno/kyverno#3119

Closed

developer-guy mentioned this pull request Sep 11, 2023

SLSA Level 3 Compliance for Oras oras-project/oras#1114

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: generate SLSA provenance for release binaries #730

feat: generate SLSA provenance for release binaries #730

laurentsimon commented Jun 14, 2022 •

edited

imjasonh left a comment

imjasonh Jun 14, 2022

laurentsimon Jun 14, 2022

laurentsimon commented Jun 14, 2022

imjasonh Jun 14, 2022

laurentsimon Jun 14, 2022 •

edited

imjasonh Jun 16, 2022

laurentsimon Jun 16, 2022 •

edited

imjasonh Jun 24, 2022

laurentsimon Jun 24, 2022

imjasonh Jun 24, 2022

laurentsimon Jun 24, 2022 •

edited

laurentsimon commented Jun 15, 2022

laurentsimon commented Jul 25, 2022 •

edited

laurentsimon Jul 25, 2022 •

edited

laurentsimon commented Jul 26, 2022

imjasonh commented Jul 27, 2022

laurentsimon commented Aug 9, 2022 •

edited

imjasonh commented Aug 9, 2022

codecov-commenter commented Aug 9, 2022 •

edited

laurentsimon commented Aug 9, 2022 •

edited

imjasonh commented Aug 9, 2022

laurentsimon commented Aug 11, 2022

laurentsimon commented Aug 16, 2022

developer-guy commented Sep 7, 2023

feat: generate SLSA provenance for release binaries #730

feat: generate SLSA provenance for release binaries #730

Conversation

laurentsimon commented Jun 14, 2022 • edited

imjasonh left a comment

Choose a reason for hiding this comment

imjasonh Jun 14, 2022

Choose a reason for hiding this comment

laurentsimon Jun 14, 2022

Choose a reason for hiding this comment

laurentsimon commented Jun 14, 2022

imjasonh Jun 14, 2022

Choose a reason for hiding this comment

laurentsimon Jun 14, 2022 • edited

Choose a reason for hiding this comment

imjasonh Jun 16, 2022

Choose a reason for hiding this comment

laurentsimon Jun 16, 2022 • edited

Choose a reason for hiding this comment

imjasonh Jun 24, 2022

Choose a reason for hiding this comment

laurentsimon Jun 24, 2022

Choose a reason for hiding this comment

imjasonh Jun 24, 2022

Choose a reason for hiding this comment

laurentsimon Jun 24, 2022 • edited

Choose a reason for hiding this comment

laurentsimon commented Jun 15, 2022

laurentsimon commented Jul 25, 2022 • edited

laurentsimon Jul 25, 2022 • edited

Choose a reason for hiding this comment

laurentsimon commented Jul 26, 2022

imjasonh commented Jul 27, 2022

laurentsimon commented Aug 9, 2022 • edited

imjasonh commented Aug 9, 2022

codecov-commenter commented Aug 9, 2022 • edited

Codecov Report

laurentsimon commented Aug 9, 2022 • edited

imjasonh commented Aug 9, 2022

laurentsimon commented Aug 11, 2022

laurentsimon commented Aug 16, 2022

developer-guy commented Sep 7, 2023

laurentsimon commented Jun 14, 2022 •

edited

laurentsimon Jun 14, 2022 •

edited

laurentsimon Jun 16, 2022 •

edited

laurentsimon Jun 24, 2022 •

edited

laurentsimon commented Jul 25, 2022 •

edited

laurentsimon Jul 25, 2022 •

edited

laurentsimon commented Aug 9, 2022 •

edited

codecov-commenter commented Aug 9, 2022 •

edited

laurentsimon commented Aug 9, 2022 •

edited