-
Notifications
You must be signed in to change notification settings - Fork 441
CICD: Add SLSA build attestation to release workflow #3563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This resolves #3468 |
I don't know much about SLSA but know that this kind of thing is important. Thanks for the PR! I'd like advice on how to bring this into production. |
Full transparency, I'm not a GHA or SLSA expert. But there wasn't much to it. I merged something (nearly the same as) this PR into main to make the workflow changes take effect, then pushed a new tag which triggers the normal release flow. The attestation step runs after the build is finished and sha256 digests produced at the end of the I don't think it is necessary to follow the way I did it -- it could be tested before including it in a real release. Since this is not a new workflow, I believe as long as the workflow changes are included in the tag that the release is built from you could experiment without an official release. For instance, I guess you could create a v0.0.0-test-slsa tag from this commit, which should trigger the release workflow because its tag pattern would match. The draft release that gets created should have the I'll try out that test procedure to make sure I am not wasting your time :) |
da12da1
to
06ecb5c
Compare
* add SLSA generator call after release step * add SLSA info and verification doc * add SLSA badge to Readme * Fix attestation doc filename, limit digest generation to files below dist/
06ecb5c
to
643b8be
Compare
I confirmed the test plan I loosely outlined does work to initiate the modified workflow. This could be used if you want to test the revised release steps and confirm the attestation document is produced as expected. git tag v0.0.0-test-slsa 643b8be7dfa85ec984a521cc17f25da6c1dc0f13
git push --tags 643b8be is the rebased squashed commit I just pushed to this PR branch. Then review GH Actions for new workflow stages: Then you could cancel or let it finish and review the attestation document as desired. If you let it run, the SLSA builder in the called workflow will submit the attestation to the public Rekor log, so there will be a history and signed digests associated with the unpublished release. I don't think that should matter, I just wanted to point it out. |
well, I apologize for the noise here. That test run in the private fork failed during the called SLSA workflow. I am investigating. I probably missed something when I was rebasing on the upstream main. |
https://github.com/eliheady/nodnsctrlo/actions/runs/14842598300 is a successful test release of this PR (plus the required one-line change for running against a private repo). I am leaving that test fork private because I'm not comfortable producing builds and a public release alongside the official releases of the project. As mentioned in 3468, this change doesn't produce SLSA attestation for the container images. I intend to make further changes to include that (if possible) in the same release workflow. If you'd prefer to wait to merge this until the docker images are also covered, it's fine with me to move this to draft status or sit on it. Also ok by me to have this merged when you are inclined to do so, with or without the container portion. I will work on it sometime this week either way. I appreciate you taking the time to consider this Tom! |
Hm. A separate release is not the intention. I have reproduced it though, and I'm afraid I just missed that it does this: in my testing I was not consistently deleting the draft releases and it seems the called workflow can reuse a release under some circumstances (that I can't characterize further at the moment). This is obviously not ready for inclusion in the project. I will do some research on this problem. |
Sounds good! |
minor update ... I have been working on a different approach using the GitHub attest-build-provenance action, which is also SLSA level 3 compliant if implemented with a reusable workflow. I think the SLSA builder approach in this current PR is going to be more challenging to implement correctly and has more potential to break. Both goreleaser and the SLSA framework project generator-generic-slsa3.yml create releases, making the duplicate release issue more likely. The GitHub provenance generator might be a better long-term solution anyway because it is integrated with the GitHub platform. There is not much different for consumers of the attestations (use |
I'll be unable to work on DNSControl until sometime later this Summer, so I am going to close this. I don't want to discourage anyone else that wants to take it up in the meantime. |
This adds a new workflow job to the release drafter workflow that calls the generic SLSA builder in the SLSA Framework project.
The draft_release job is modified to include a new step to generate sha256 digests according to the expected input of the SLSA builder.
The release assets will include a new file called
multiple.intoto.jsonl
that can be used to verify the build artifacts against the recorded digests. This is what it will look like on the releases page:This was tested in a private fork because I didn't want to introduce any confusion around DNSControl releases in the public Rekor logs. I will give read access to interested reviewers.
Example artifacts are attached. Manual verification steps:
checksums.txt
multiple.intoto.jsonl.txt
Note the attestation document has been renamed just for attaching to this issue, GitHub blocks
jsonl
(?)Release changelog section