Pin the remaining actions and scope job permissions

[kwsantiago]

Summary

Pins the eight action references that were still mutable tags, scopes permissions on all six jobs, and stops every checkout persisting the job token.

Why now

#162 added Dependabot and fixed the unverified Zig toolchain download in ci.yml, but only ci.yml had its actions pinned. benchmark.yml and release.yml were untouched and still carried bare tags. The Dependabot run that followed made that visible: it bumped the pinned refs in ci.yml to new commit SHAs while the others simply moved from @v4 to @v7, still mutable.

The release path is the part that matters. docker/login-action authenticates to ghcr.io and docker/build-push-action pushes the published image, and both were reached through tags their owners can move at any time. softprops/action-gh-release creates the release itself.

Permissions

Assigned per job rather than blanket contents: read, because two jobs genuinely need write and a uniform rule would have broken the release:

job	permission	why
ci: build, ci: integration, benchmark, release: build	contents: read	build and test only
release: docker	contents: read, packages: write	pushes to ghcr.io/${{ github.repository }}
release: release	contents: write	creates the GitHub release

Every job previously ran with the default token scope.

Audit after the change

property	before	after
action refs pinned to a commit	7/15	15/15
jobs with explicit permissions	0/6	6/6
checkouts with persist-credentials: false	1/5	5/5

Test plan

• All three workflow files parse as YAML after the rewrite
• Each SHA resolved from the tag it replaces, so no version changes: actions/checkout v7.0.1, download-artifact v8.0.1, upload-artifact v7.0.1, docker/build-push-action v7.3.0, docker/login-action v4.6.0, docker/metadata-action v6.2.0, mlugg/setup-zig v2.2.1, softprops/action-gh-release v3.0.2
• Job permissions derived from what each job actually does, read from its step list rather than assumed
• CI green

The release and docker jobs only run on tag pushes, so this PR's CI does not exercise them. Their permission scopes are the one part that will not be proven until the next release, which is worth knowing before cutting one.

Summary by CodeRabbit

• Chores
  • Improved the security and reproducibility of automated benchmark, CI, and release workflows.
  • Restricted workflow permissions to read-only access where applicable.
  • Pinned build, packaging, artifact, and release actions to fixed versions.
  • Disabled persistent checkout credentials during automated jobs.

[coderabbitai]

Warning

Review limit reached

@kwsantiago, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 54 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8781c7e6-6974-4031-9e00-ce4147480b07

📥 Commits

Reviewing files that changed from the base of the PR and between a36be75 and 8ee50f2.

📒 Files selected for processing (1)

• .github/workflows/release.yml

Walkthrough

The workflows now use explicit read-only or write permissions where required. GitHub Actions references are pinned to commit SHAs. Checkout steps disable persisted credentials across benchmark and release jobs.

Changes

Workflow hardening

Layer / File(s)	Summary
CI and benchmark workflow controls .github/workflows/benchmark.yml, .github/workflows/ci.yml	Benchmark actions use pinned commits and disabled checkout credentials. CI build and integration jobs define read-only contents access.
Release build controls .github/workflows/release.yml	The release build job defines read-only contents access and pins checkout and Zig setup actions.
Release delivery controls .github/workflows/release.yml	Docker and release jobs pin action commits and define contents and package permissions for artifact, image, and release operations.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• privkeyio/wisp#162: Both PRs modify the build and integration jobs in .github/workflows/ci.yml, but they address different CI hardening aspects.

Poem

A rabbit checks each workflow line,
With pinned steps in neat design.
Read-only paws where reads are due,
And saved keys vanish from the queue.
The release path hops safely through.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main changes: pinning GitHub Actions and scoping job permissions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch pin-remaining-actions

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release.yml:
- Around line 50-52: Add use-cache: false to the mlugg/setup-zig step’s with
configuration in the release workflow, while preserving the existing Zig version
and trusted tarball cache behavior.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5cc340f1-f66f-40c2-be9d-853e20e90f1d

📥 Commits

Reviewing files that changed from the base of the PR and between d92eb31 and a36be75.

📒 Files selected for processing (3)

• .github/workflows/benchmark.yml
• .github/workflows/ci.yml
• .github/workflows/release.yml

[kwsantiago]

Valid, and applied to the release job only.

Checked the action's own action.yml at the pinned SHA rather than assuming what the input does. use-cache (default true) covers "the global and local Zig cache directories", which is the build cache, distinct from use-tool-cache, which covers the compiler installation. So this is about compilation output, not the toolchain download.

That distinction is what makes it worth doing here: those directories are restored from the GitHub Actions cache, and other workflow runs in this repository can write to that cache. A published binary should not be able to pick up compilation output that something other than its own run produced. The cost is a full rebuild per release, which is the right trade for an artifact people download.

Scoped to release.yml. ci.yml and benchmark.yml keep caching, since their output is not published and the speed matters more there.

Worth noting the limit of this change: it does not make the release build reproducible, and it does not verify the toolchain itself. mlugg/setup-zig fetches Zig and checks it against the official minisign key, which is a stronger guarantee than the raw curl | tar that ci.yml used before #162, but neither this nor that gives byte-for-byte reproducibility the way keep-android's apksigcopier compare job does. If reproducible releases are wanted for wisp, that is a separate piece of work.