[napetrov]

Summary

Signs release artifacts and attaches build provenance, so OpenSSF Scorecard's Signed-Releases check (0 today) can score.

release.yml attach job:

• actions/attest-build-provenance on dist/*: SLSA provenance, also stored in the repo's attestations (gh attestation verify)
• sigstore/gh-action-sigstore-python: keyless signature per file, using the workflow's OIDC identity → <file>.sigstore.json
• uploads sdist, wheel, *.sigstore.json and dokimi-X.Y.Z.intoto.jsonl to the release

docs/releasing.md gets a "Verifying a release" section.

Evidence

• zizmor: no findings. tests/test_dependency_locks.py passes.
• Action inputs and outputs checked against the pinned tags: v3.5.0 writes <file>.sigstore.json, v4.2.2 outputs bundle-path. Both are Scorecard-recognised extensions.
• Not run end to end: that needs a published release. The first real check is the next release (or a test tag on a fork).

Merge danger

Low. Only the release-event job changes, and it now needs id-token: write and attestations: write. v0.1.0 stays unsigned, and Scorecard scores the last 5 releases, so the score climbs over the next releases.

Self-reviewed locally (pr-review, 2 passes, no blocking left).

🤖 Generated with Claude Code

[exai-bot]

🔍 OpenCodeReview found 1 issue(s) in this PR.

CI at b9fd10f: 15 passing, 2 skipped.

By severity: 1 medium

Severity	Category	Location	Finding
medium	bug	releasing.md:103	Must-fix.

Review details

• Commit reviewed: b9fd10f against merge base 0e993b9
• Coverage: 3 files in 1 groups
• Engine: OpenCodeReview v1.13.5-exai.3.d7112371, us.openai.gpt-6.1-sol
• Usage: 75k tokens (56k from cache), 17s
• Tool calls: 4 (1 code_comment, 1 code_search, 1 file_read, 1 pr_threads)
• small change set: 3 files

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

3 open issues

• dist/* is very broad and will start including additional files as the workflow evolves (e.g., if… · New
• The verification commands hardcode intel/dokimi, which makes the documentation less reusable for… · New
• The phrase “also in gh attestation verify” is ambiguous (the command isn’t a location). Consider… · New

What changed in this PR

Adds Sigstore signing and SLSA build provenance publishing to the GitHub Release workflow, and documents how consumers can verify release artifacts.

Changes:

• Update release workflow to generate build provenance and Sigstore bundles, then upload them alongside sdist/wheel assets.
• Document verification steps for signatures and provenance in the release procedure.
• Add a changelog entry announcing signed releases/provenance.

File	Description
.github/​workflows/​release.yml	Attests build provenance, performs Sigstore signing, and uploads signatures/provenance to the GitHub Release.
dokimi/​docs/​releasing.md	Adds “Verifying a release” section with CLI steps to verify signatures and provenance.
dokimi/​changelog.d/​20261105_120000_napetrov_signed-releases.md	Announces the new signing + provenance release behavior.

_{Review effort: Lite}

[exai-bot]

Must-fix. Impact: the documented Sigstore verification rejects genuine release signatures. Trigger: running this command on a signed wheel (the same problem affects the sdist). Evidence: sigstore verify github --name selects the workflow filename in the certificate identity, not the YAML display name; the signer identity ends in .github/workflows/release.yml@refs/tags/vX.Y.Z, whereas --name release expects .github/workflows/release@refs/tags/vX.Y.Z. Workaround: use --name release.yml. Severity: medium because the advertised verification path fails, although signing itself is unaffected.

Suggestion:

Suggested change

	--repository intel/dokimi --ref refs/tags/vX.Y.Z --name release
	--repository intel/dokimi --ref refs/tags/vX.Y.Z --name release.yml

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.78%. Comparing base (7fa98b9) to head (b9fd10f).
⚠️ Report is 2 commits behind head on main.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #415   +/-   ##
=======================================
  Coverage   94.78%   94.78%           
=======================================
  Files         353      354    +1     
  Lines       46527    46588   +61     
  Branches     7967     7974    +7     
=======================================
+ Hits        44100    44159   +59     
- Misses       1540     1541    +1     
- Partials      887      888    +1     

see 11 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[antonwolfy]

LGTM. The attach job orders the steps correctly: provenance is attested on dist/* before signing, so no .sigstore.json is an attestation subject, and the extra permissions are scoped to that job only. The pypi job still receives only the sdist and wheel, because attach uploads no artifact. I agree with Copilot's low point that "also in gh attestation verify" in the changelog fragment reads oddly.

What I ran, on a Linux review host at b9fd10f:

• make ci-local: 30 passed, 0 failed, 7 skipped (job conditions, docker/micromamba/semgrep not available).
• zizmor --offline on release.yml: no findings. mkdocs build --strict: passes, and the #verifying-a-release anchor resolves.
• Not run: the signing and verification commands. They need a published release, as the description says.

Checked, no issues

• Order and uploads: the cp of the provenance bundle goes through an env var, and gh release upload dist/* sends the sdist, wheel, bundles and .intoto.jsonl.
• Docs and workflow: file names and the --signer-workflow path in releasing.md match what the workflow produces.

Bot points I checked that no longer apply at this head (3)

• Copilot's point on dist/* does not apply: the dist artifact is built by the build job and holds only the sdist and wheel at the attestation step, and signing runs after it.
• Copilot's point on hardcoding intel/dokimi does not apply: the commands pin the expected repository on purpose, so a verifier does not accept a signature from another repository.
• exai-bot's point on --name release does not apply: sigstore verify github --name matches the workflow's name: field (the certificate's workflow-name extension) according to the sigstore-python documentation, and release.yml has name: release. I did not run sigstore verify, so this is from the documentation.