The release workflow runs a third-party action from a moving branch

[adamtheturtle]

What happens

.github/workflows/release.yml:44 uses a third-party action pinned to a moving branch:

uses: StephaneBour/actions-calver@master

.github/workflows/test.yml:156 does the same with jlumbroso/free-disk-space@main.

zizmor would flag both, but unpinned-uses is disabled in zizmor.yml:

rules:
  unpinned-uses:
    disable: true

Why it matters

The two cases are not equivalent.

actions-calver runs in the release workflow. That job has write permissions, it commits back to the repository through stefanzweifel/git-auto-commit-action, it tags, and the release chain it starts ends at pypa/gh-action-pypi-publish with id-token: write and at docker/login-action pushing to GHCR. A change to master in that repository — whether malicious or simply a bad release — executes inside that chain with no review and no way to tell after the fact which revision ran.

free-disk-space@main is in the test workflow, which has permissions: {} at the top level, so the exposure is much smaller.

The rest of the workflows use tags such as actions/checkout@v7 and astral-sh/setup-uv@v9.0.0. Tags are also mutable, but they are at least a version the maintainer chose, which @master is not.

Suggested resolution

Pin the actions in release.yml to full commit SHAs, with a comment giving the version, which is the usual form:

uses: StephaneBour/actions-calver@<sha>  # v1.x.x

Dependabot's github_actions ecosystem updates SHA pins and keeps the version comment in sync, and it is already configured for this repository, so this does not create ongoing manual work.

Whether to pin the non-release workflows too is a separate judgement. If they are pinned, unpinned-uses can be re-enabled in zizmor.yml and the property is then enforced rather than remembered. If not, it is worth recording in zizmor.yml why the rule is off, since the current disable: true gives no reason and the release workflow is a case the rule would have caught.

[adamtheturtle]

Reading release.yml more closely, the exposure is larger than the description says, so it is worth recording here.

The checkout at the top of the release job persists a PAT which is specifically chosen because it can bypass the branch ruleset:

          # Use a PAT so that the push from git-auto-commit-action
          # can bypass repository ruleset required status checks.
          # The default GITHUB_TOKEN cannot bypass rulesets.
          token: ${{ secrets.RELEASE_PAT }}
          persist-credentials: true

persist-credentials: true writes that PAT into .git/config as an extraheader, where it stays for the rest of the job. StephaneBour/actions-calver@master is the third step of that same job, so it runs with a ruleset-bypassing credential sitting in the working directory — readable by any step, not just by the ones the token was meant for.

So a bad revision of master in that repository would not just run inside the release chain, it could push directly to main past the require-builds ruleset which otherwise gates every merge.

The # zizmor: ignore[artipacked] on the checkout shows the persisted credential itself was a considered tradeoff for git-auto-commit-action, which is reasonable. The part I doubt was considered is that it combines with an unpinned third-party action in the same job.

This does not change the suggested fix, but it does argue for doing the release workflow first rather than treating all three unpinned uses as equivalent. jlumbroso/free-disk-space@main in test.yml remains the low-stakes one — that job has permissions: {} and no persisted credential.