Skip to content

Pin GitHub Actions to commit SHAs in PyPI publish workflow - #48

Open
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/25-pin-action-shas
Open

Pin GitHub Actions to commit SHAs in PyPI publish workflow#48
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/25-pin-action-shas

Conversation

@elhoim

@elhoim elhoim commented Aug 31, 2026

Copy link
Copy Markdown
Member

Finding 25 (Medium) — .github/workflows/pypi-publish.yml:17,20,31,48,110

Problem

actions/checkout@v4, setup-python@v5, upload-artifact@v4, download-artifact@v4 and pypa/gh-action-pypi-publish@release/v1 are pinned to MUTABLE tags on a job carrying id-token: write for PyPI trusted publishing. A repointed tag would run untrusted code with publish rights.

Fix

The PyPI publish workflow (.github/workflows/pypi-publish.yml) referenced actions/checkout@v4, actions/setup-python@v5, actions/upload-artifact@v4, actions/download-artifact@v4, and pypa/gh-action-pypi-publish@release/v1 by mutable tag/branch refs, while the publish job carries id-token: write for PyPI trusted publishing — a repointed tag or compromised release branch could have executed untrusted code with publish rights. Fixed by pinning each action to its current full 40-character commit SHA (resolved live via git ls-remote against the upstream actions/pypa repos), with the corresponding semantic version kept as a trailing comment for readability/maintainability.

Verification

Reproduced against the unmodified code at 9b8c605, then re-checked after the change.

Before
Ran a small inspection script (/tmp/repro_pin.py) that greps `uses:` lines in the workflow and flags any not pinned to a 40-hex-char commit SHA:
uses lines found: ['actions/checkout@v4', 'actions/setup-python@v5', 'actions/upload-artifact@v4', 'actions/download-artifact@v4', 'pypa/gh-action-pypi-publish@release/v1']
mutable (non-SHA-pinned) refs: ['actions/checkout@v4', 'actions/setup-python@v5', 'actions/upload-artifact@v4', 'actions/download-artifact@v4', 'pypa/gh-action-pypi-publish@release/v1']
BUG: job with id-token: write trusts mutable tags: [...]
After
Same script after the fix:
uses lines found: ['actions/checkout@11d5960a326750d5838078e36cf38b85af677262', 'actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065', 'actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02', 'actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093', 'pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33']
mutable (non-SHA-pinned) refs: []
OK: all actions pinned to full commit SHAs

python bin/cli.py --help exits 0 and the module still imports cleanly. Verification was performed offline against the pure functions — no running misp-modules instance is required.

Branched from 9b8c605. This PR addresses only this finding; the other findings from the same review are in separate PRs, so they will need rebasing against each other as they merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DYX4TKA5inzByJ4qGWKjqh

The build/publish workflow referenced actions/checkout@v4, actions/setup-python@v5, actions/upload-artifact@v4, actions/download-artifact@v4 and pypa/gh-action-pypi-publish@release/v1 by mutable tag/branch names. The publish job carries id-token: write for PyPI trusted publishing, so a repointed tag or compromised release branch could run untrusted code with publish rights. Pin every action to its current full commit SHA (with the corresponding version as a trailing comment) to eliminate that supply-chain surface.
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.

1 participant