bun-pypi

Pins to at workflow scope. The three jobs (, , ) run , + pytest across an OS/Python matrix, and + upload-artifact. No registry push, no GitHub API write. Defense-in-depth motivation is the CVE-2025-30066 precedent: a compromised third-party action (e.g. , , both used here) runs inside the existing job context and exfiltrates the workflow via build logs. Pinning the workflow to read-only caps the blast radius. Style matches the workflow-level block already in . YAML validated locally with .

I work on software supply chain security and have been hardening GitHub Actions workflows across OSS projects. Each of these workflows runs without a top-level block, so its inherits the repository (or org) default, which is frequently read/write for all scopes. This PR sets at the workflow level for , which is all these jobs need (checkout plus the build/test steps). Scoping the token to read-only shrinks what a compromised step or dependency can do, a concern made concrete by the March 2025 compromise (CVE-2025-30066), where a leaked write-scoped was the blast radius. No job behavior changes; the steps already only read the repository.