Generate SLSA provenance for released binaries#9702
Generate SLSA provenance for released binaries#9702laurentsimon wants to merge 20 commits intodocker:mainfrom
Conversation
|
|
||
| - name: Compute checksums | ||
| run: cd bin; for f in *; do shasum --binary --algorithm 256 $f | tee -a checksums.txt > $f.sha256; done | ||
| working-directory: bin/ |
There was a problem hiding this comment.
note: this change is not needed. I added working-directory to avoid the cd bin, but I can revert.
laurentsimon
force-pushed
the
feat/slsa3
branch
from
15c3a06 to
51d3f7e
Compare
|
friendly ping. Are there any question I could answer? |
nicksieger
left a comment
nicksieger
left a comment
There was a problem hiding this comment.
LGTM, thanks for setting this up.
| - uses: actions/download-artifact@v3 | ||
| with: | ||
| name: "${{ needs.provenance.outputs.attestation-name }}" | ||
| # Upload to release. |
There was a problem hiding this comment.
| # Upload to release. | |
| # Verify binaries if dry run | |
| - name: Verify binaries | |
| if: 'inputs.dry-run' | |
| run: | | |
| echo TODO: verify with slsa-verifier | |
| # Upload to release. |
There was a problem hiding this comment.
I guess we need to put in the actual steps here. Don't suppose you have a packaged action for verifying yet?
There was a problem hiding this comment.
Not yet, but we are working on it.
Would you like me to add the steps in this PR or do that in a follow-up PR?
We have 2 options:
go install ...@vx.y. This will build from source. Takes about 2-3mn for the verifier to build- pull the binary from our release. This would allow simulating what users do, ie using the latest version of the verifier. (Note: we can verify the hash of the pulled binary)
Let me know what you prefer.
There was a problem hiding this comment.
The cheapest option is to use the pre-compiled binary. But if you don't mind 2-3mn to build the verifier, it's the simplest option.
There was a problem hiding this comment.
I added the code for verification. PTAL
I also created a tracking issue slsa-framework/slsa-verifier#206 on our repo as an AI to send a PR to update your workflow when we have the GHA released.
|
Thanks @nicksieger ! |
.github/workflows/release.yaml
Outdated
| name: "${{ needs.provenance.outputs.attestation-name }}" | ||
| # Verify binaries if dry run | ||
| - name: Verify binaries | ||
| if: 'inputs.dry-run' |
There was a problem hiding this comment.
it seems like SLSA provenance is generated either way
There was a problem hiding this comment.
It doesn't only have to be on a dry run. On a real release it's theoretically extra work, but might still be nice to make sure the attestation loop is complete?
There was a problem hiding this comment.
I've made the changes so that the verification happens in any both cases.
laurentsimon
force-pushed
the
feat/slsa3
branch
from
d567fb3 to
b2f6510
Compare
Co-authored-by: Nick Sieger <nicksieger@gmail.com> Signed-off-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com> Signed-off-by: laurentsimon <laurentsimon@google.com>
Co-authored-by: Nick Sieger <nicksieger@gmail.com> Signed-off-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com> Signed-off-by: laurentsimon <laurentsimon@google.com>
Co-authored-by: Nick Sieger <nicksieger@gmail.com> Signed-off-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com> Signed-off-by: laurentsimon <laurentsimon@google.com>
Can give 1.19 a bit of time before we upgrade ;) Signed-off-by: Milas Bowman <milas.bowman@docker.com> Signed-off-by: laurentsimon <laurentsimon@google.com>
Signed-off-by: laurentsimon <laurentsimon@google.com>
laurentsimon
force-pushed
the
feat/slsa3
branch
from
f84a9fe to
004fe6e
Compare
|
friendly ping for feedback. |
|
Hello @laurentsimon Regarding the current exchanges in your buildx PR, we're discussing internally to give you a common response quickly. |
Absolutely. SGTM. Happy to answer further questions if you have any. |
5 participants
Hi,
I'm reaching out on behalf of the Open Source Security Foundation (openssf.org). We work on improving the security of critical open source projects like yours.
Together with GitHub, we designed a free, easy-to-use method of code signing. It will help your users verify that your release binaries were built from your repository’s workflow and not altered by anyone. It’s just a few lines of code, but it will make your project more secure against third-party tampering and attacks like Codecov and CTX.
This PR shows how to add this seamless code signing to your workflow. You don’t have to be a cryptography expert or learn complicated tools and verification is simple for your users.
You can read more on the SLSA blog. Please reach out if you have any questions!