Provide output containing hash of the provenance file

[chipzoller]

Since the provenance file (in attested format) gets uploaded, users may need to download that in another job to attach it as an attestation to an image. Making sure the same file that was uploaded by this action is the same that was downloaded for further processing would be a nice enhancement to security and cut out additional steps.

[laurentsimon]

Thanks for the suggestion. By uploaded, do you mean to rekor or to the release assets?

[chipzoller]

Release asset to ensure integrity and tamper detection across subsequent jobs in the same workflow.

[laurentsimon]

I see. Thanks for the information. sha256 would be simple, you're right. We have this issue https://github.com/slsa-framework/slsa-verifier/issues/95 about creating an Action for the verifier, so that you can download and verify binary, which in your case would indicate the binary/provenance are correct.

Let me know if this would be appropriate, if you feel a hash would be better. Note that once we support multiple builds, the output will probably become a JSON string... or something else like a sha256sum file <sha256> <filename> on each line.

Feedback welcome!

[chipzoller]

I really just want an output on this action (not slsa-verifier which I don't need), or some simple way to set one, for the provenance JSON file. That's it.

And also, on that point, I really only want that provenance JSON file uploaded, not anything else. So having that as an available input here would be ideal. For example, if I'm building a container image that has a Go app in a ko-based pipeline, I don't need the artifact binary since it's been built as a part of the image and pushed to an OCI registry. I just need the provenance so I can attest to it.

[laurentsimon]

I just need the provenance so I can attest to it.

Do you mean you would be building the container yourself, and use the re-usable workflow in this repo to sign the attestation? If this is what you have in mind, the generic provenance workflow is what you may want to use https://github.com/slsa-framework/slsa-github-generator#other-projects - we're working on adding support for container images in registries, instead of just arbitrary binaries (current state). /cc @ianlewis

If instead you want the re-usable workflow to build-then-create-and-sign-provenance, we're also working on it https://github.com/slsa-framework/slsa-github-generator/issues/23

Or maybe you want us to create the provenance and let you sign it? I was thinking that our re-usable workflow could take an additional input key-type that would be github-keyless by default, but that could be set to google-kms and additionally-needed parameters; and the re-usable workflow would perform the signing

Please let us know.

[ianlewis]

And also, on that point, I really only want that provenance JSON file uploaded, not anything else. So having that as an available input here would be ideal. For example, if I'm building a container image that has a Go app in a ko-based pipeline, I don't need the artifact binary since it's been built as a part of the image and pushed to an OCI registry. I just need the provenance so I can attest to it.

Hi! thanks for taking a look at the project! Could you explain what you mean by "attest to it"? Do you mean checking the sha hash you're describing?

The provenance itself is signed using a key tied to the Github OIDC identity of the reusable workflow. This signature is a stronger assurance that the provenance was created by the workflow and hasn't been tampered with. I think we want to encourage folks to use slsa-verifier as that will check the signature and other aspects of the provenance so I would like to better understand the use case for having a sha before adding it.

[chipzoller]

Sure, I'll respond to both comments.

From @laurentsimon:

Do you mean you would be building the container yourself, and use the re-usable workflow in this repo to sign the attestation? If this is what you have in mind, the generic provenance workflow is what you may want to use https://github.com/slsa-framework/slsa-github-generator#other-projects - we're working on adding support for container images in registries, instead of just arbitrary binaries https://github.com/slsa-framework/slsa-github-generator/issues/178.

What I'm wanting is to build a container image and generate the provenance for it. It just so happens that the container image "wraps" a Go app but I don't care about building and offering (in this case anyway) the Go app as a standalone binary, only as a container image.

From @ianlewis:

Could you explain what you mean by "attest to it"? Do you mean checking the sha hash you're describing?

Per the previous comment, the goal is to build a container image and produce a SLSA provenance for that container image. Seeing as how the current version offers Golang support, I started to use it because it seemed most appropriate. The offered workflow uploads a predicate that is already in in-toto attestation format. When using the command cosign attest you must pass it a file with the --predicate flag. There is also a --type flag of which one of the allowable values is slsaprovenance. In order for that particular value to be used, the file being passed to --predicate must be in unattested format. Therefore I found it necessary to, in a later step after the slsa-github-generator runs and uploads this JSONL file, download it and strip out the raw predicate as you can see from the below workflow snippet I've created:

    - name: Download attestations
      uses: actions/download-artifact@fb598a63ae348fa914e94cd0ff38f362e927b741 # v3.0.0
      with:
        name: binary-linux-amd64.intoto.jsonl
    - name: Strip predicate
      run: jq -r .payload binary-linux-amd64.intoto.jsonl | base64 --decode | jq .predicate > provenance.json

Once the resulting "cleaned" provenance document is provided, it can be used in cosign attest to attach to the container image which was previously uploaded.

The request to provide a hash of the JSONL file produced by slsa-github-generator was to help ensure that, in the later job which contains the steps shown above, once the file was downloaded it was not tampered. This detection would be made by comparing the hash (set as an environment variable) to the one computed from the file downloaded as an artifact. If you created this as an output to the workflow, it makes this job far easier than hacking at it individually.

Maybe the steps I've gone through are completely asinine and, if so, please tell me and coach me up, but it was an attempt to get an "official" SLSA predicate type provenance for a Go app built as a container.

[ianlewis]

Ah, ok. I see. In this case the provenance is saying the go binary included in the build is built with the workflow but doesn't say anything about the container. So verification is a bit difficult because you'd have to extract the Go binary from the container image to verify it.

What you'd probably want to do in this case is use the generic provenance generator. Though, currently it's not particularly container friendly as you'd need to get a file artifact to verify it using slsa-verifier. I'm not sure that docker save would produce the exact same file from an image in a reproducible manner.

So I think the proper answer right now is wait a few weeks and we'll have better support for container image artifacts. Some issues you can track are:

• 57

• 332

• 178

[chipzoller]

Thanks for this, Ian. I think it may be best to just wait and watch (and contribute) once you all have built the container image provenance generation capability out. I'll subscribe to these threads and this repo in the mean time.

[laurentsimon]

@chipzoller we'd love to have you as a contributor!