Skip to content

Pin coverage and PyPI publishing actions - #210

Open
ryanduguid wants to merge 3 commits into
csingley:masterfrom
ryanduguid:codex/pin-publishing-actions-20261017
Open

ryanduguid wants to merge 3 commits into
csingley:masterfrom
ryanduguid:codex/pin-publishing-actions-20261017

Conversation

@ryanduguid

@ryanduguid ryanduguid commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Pin the Coveralls and PyPI publishing actions to the commits currently referenced by v2 and release/v1. Keep each moving reference as a comment.

Evidence

  • Both public refs still resolve to the pinned commits. The publishing image is available under both the commit and release-v1 tags; both resolve to sha256:a68d05519f6d7e47372aeaddab80b851b69afa89be179ec41775c72c4e3ab2d5.
  • The two-line patch applies to the recorded upstream base and passes actionlint and whitespace checks.
  • The offline workflow scan reports two fewer unpinned-action findings, with its existing credential-persistence, permission and other unpinned-action findings retained.

Risk

Future updates to these two actions require an explicit commit-pin update. The publishing action derives its container tag from the action ref; its pinned build supports SHA tags and records a successful image push.

Unverified

Hosted CI and publishing were not exercised. Ruff, formatting, mypy and pytest were not rerun for this two-line workflow change. Existing source findings remain outside this contribution.

@csingley

Copy link
Copy Markdown
Owner

Hey @ryanduguid ... why do you want to do this?

@ryanduguid

Copy link
Copy Markdown
Contributor Author

This pins the coverage and PyPI publishing Action code to fixed commits. The existing v2 and release/v1 refs can move; SHAs make subsequent updates explicit and reviewable in a PR.

@csingley

Copy link
Copy Markdown
Owner

Why do you want to do that? It isn't necessary for reproducibility. Is your motivation security related? I would like to understand what goal you are aiming for, and how this change accomplishes that goal.

@ryanduguid

Copy link
Copy Markdown
Contributor Author

Yes, it's security rather than reproducibility. A tag like release/v1 can be moved to different code by whoever controls the action's repository, and the publish job runs that code with permission to upload to PyPI. A tag moved by a compromised account would run in that job on the next release, as happened with tj-actions/changed-files in 2025. Pinning a commit means an action update only happens through a reviewed change here.

If you'd rather keep the tags, that's fine. I'll close this.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants