ci: Set read-only token permissions #1964

pull fametrano wants to merge 1 commits into bitcoin-core:master from fametrano:ci-harden-permissions-pins changing 1 files +3 −0

fametrano commented at 12:39 PM on October 13, 2026: contributor

This sets permissions: contents: read for the CI workflow. The matching change in Bitcoin Core, bitcoin/bitcoin#36513 for bitcoin/bitcoin#36512, was closed unmerged; see this comment.

Part of #1959.
fametrano force-pushed on Oct 13, 2026
fametrano commented at 7:09 PM on October 13, 2026: contributor

I dropped persist-credentials: false to stay in sync with Core, where review found it adds nothing once the token is read-only (https://github.com/bitcoin/bitcoin/pull/36513#issuecomment-6146223556). The PR now only sets permissions: contents: read.
theStack added the label ci on Oct 16, 2026

ci: Set read-only token permissions

Give GITHUB_TOKEN only `contents: read`.

Part of #1959.

e9e700f8dc

fametrano force-pushed on Oct 25, 2026
fametrano commented at 7:18 PM on November 3, 2026: contributor

real-or-random's Concept ACK on #1959 asked to keep this in sync with what Bitcoin Core does, and Core's ci.yml today sets no permissions:.

I closed bitcoin/bitcoin#36513, a similar PR, because @hebasto deemed it controversial and I had been asked to reduce my open PRs. Frankly, I do not understand why the change would be controversial. hebasto found demoting packages to none good in principle but without practical effect on Core's CI, which is true. He also wrote that enforcing permissions on behalf of forks seems outside the project's scope; but a fork gets the workflow file with its permissions: block, and its owner can change it.

I see permissions: contents: read as simple hygiene in software development, but if the criterion is to conform to Core, I will close this PR too.

Contributors

Labels