Repository navigation
Attest the tagged workbook on the draft release - #225
Merged
Merged
Conversation
OpenSSF Scorecard gives Signed-Releases 0/10 because releases carry only the custom provenance.json. attest-release.yml runs on the signed tag while the release is a draft. It requires a verified annotated tag on the run's commit, a successful verify-gates push run on main for that commit (release-policy's required_checks.py at the pin the VirusTotal workflow uses), exactly the three bundle assets with matching API digests, a passing prepare_release_bundle.py verify and a draft workbook byte-identical to the tagged one. It then attests the tagged ozzit.xlsx with actions/attest v4.2.2, verifies the attestation through the API and the bundle, and uploads ozzit-X.Y.Z.intoto.jsonl. The bundle sits outside SHA256SUMS, as RELEASING.md now states. An immutable release accepts no asset after publication, so v3.5.0 and earlier stay without one.
From the final review of the attestation workflow: - The signed tag's own name must equal the dispatched ref, so another ref pointing at a signed object cannot stand in for a different version. - The draft's ID, tag name and three assets (ID, digest, size, state) are recorded when verified. Before upload the draft must still match and the tag must still name the verified object; the bundle is then uploaded to that release ID instead of resolving the tag again. After upload the three assets must be unchanged and the bundle the only addition. - RELEASING.md makes immutable releases a prerequisite, since only immutable publication stops an upload racing a maintainer's publish; describes the required-check run as a trusted push or workflow_dispatch run of main; drops an incorrect checksum-cycle rationale; and gives explicit paths in the verifier's commands.
Release jobs elsewhere pin ubuntu-24.04 (release-policy #183) so the label's move to Ubuntu 26 cannot change the runner mid-release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
Adds a manual
Attest releaseworkflow. It signs build provenance for the taggedozzit.xlsxand adds the bundle,ozzit-X.Y.Z.intoto.jsonl, to the draft release before it is published. RELEASING.md places the step.Why
OpenSSF Scorecard scores Ozzit 0/10 on Signed-Releases, because releases ship a custom
provenance.jsonthat Scorecard does not recognise. A Sigstore*.intoto.jsonlbundle on the release is what it counts. The workbook is built and gated with native Excel on Windows, so CI cannot rebuild it. Instead this attests the tracked workbook at the signed tag, after checking that the draft's copy is byte-identical. No computed number, rate or threshold changes.Verification
tools/tests/test_repository_policy.pygains tests for the new workflow's policy: its trigger, permissions, verification steps, upload guards and the RELEASING.md step. Rust gates are unaffected: no file undertools/ozzitchanges.Final review
ubuntu-latest, which GitHub is moving to Ubuntu 26, so they now pinubuntu-24.04, as release-policy's release jobs do.checksjob uses release-policy a601f1d, the commit Ozzit's VirusTotal workflow already pins. Door: two-way; the workflow only runs when dispatched by hand. Blast radius: the next release's draft.Checklist
.envcontents, appear in the diff, the commit messages or this description.