Skip to content

ci: pin least-privilege token permissions on the ci workflow - #86

Open
cargo-affected-bot wants to merge 1 commit into
mainfrom
ci/least-privilege-token
Open

ci: pin least-privilege token permissions on the ci workflow#86
cargo-affected-bot wants to merge 1 commit into
mainfrom
ci/least-privilege-token

Conversation

@cargo-affected-bot

Copy link
Copy Markdown
Collaborator

Nightly survey finding on .github/workflows/ci.yaml.

ci.yaml is the only workflow in this repo with no permissions: block — release.yaml and all eight tend-*.yaml files pin their own. Without the key the GITHUB_TOKEN inherits the repository-wide default, which on a push to main can carry write scopes across contents, packages, and more.

None of the three jobs needs any of that. actions/checkout is the only step in the file that touches the GitHub API, and contents: read covers it. Swatinem/rust-cache uses the Actions cache service (its own ACTIONS_* credentials, not the GITHUB_TOKEN), baptiste0928/cargo-install builds from crates.io, and nothing in the workflow references GITHUB_TOKEN or secrets.* at all.

This is the same change the maintainer already landed for release.yaml in #66, applied to the last workflow still missing it.

No regression test. This is workflow configuration with no code path a test could exercise; the change is verified by CI on this PR running green under the restricted token. I confirmed the YAML parses and that the three jobs are unchanged apart from the added key.

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