ci: Limit workflow token to contents: read #36512

The workflow sets no permissions:, and actions/checkout leaves the job's token in .git/config, where any later step can read it.

Nothing is exploitable today: the token is already read-only (the job logs show Contents: read, Metadata: read, Packages: read) and no step writes with it. Setting permissions: contents: read and persist-credentials: false makes that explicit, for forks too.

Pinning actions by hash is left out, after #35754.

libsecp256k1 wants to stay in sync with Core here (bitcoin-core/secp256k1#1959), and I am opening the same change there.

Not sure about this, as mentioned previously: Container and GitHub Action pins are not done, because they: - delay normal and security updates until someone bumps the pin; - require recurring manual maintenance; - are not recursive, so they can create false confidence about reproducibility and security

So there is something done in the name of "security", but there is a valid risk of actually decreasing "security".

in March 2025 that printed CI secrets

I am sure that even with pinned actions, anyone is still free to print CI secrets, if they want:

• GitHub itself (they can already do whatever they want)
• The provider for the CI machines (they provide the hardware, so they can do whatever they want)
• Any action that is pinned, by just doing the printing in a mutable included action
• Likely any other ci package/dependency inside the container can do printing (assuming the secret makes it into the container)
• ... etc

If we are worried about CI printing secrets, the solution is not to pin. The solution is not to provide any secrets.

Nothing is exploitable today: the token is already read-only (the job logs show Contents: read, Metadata: read, Packages: read) and no step writes with it. Setting permissions: contents: read and persist-credentials: false

Seems fine. This was my criticisms about moving to GHA, and I am not familiar with their permission system for credentials. Though, if there is a reason/benefit making this stricter, it seems fine. But other people more familiar with GHA permissions would have to review that.

Thanks. I missed #35754 and take the point that pins are laborious to maintain and not recursive, so I leave them out. Since tags have been repointed to malicious commits before (tj-actions/changed-files, GHSA-mrrh-fwg8-r2c3), I may open a separate issue on pinning if that seems worth discussing.

The PR will carry only permissions: contents: read and persist-credentials: false. I'd welcome review from someone who knows GHA permissions.

Closing for now. No need to keep an issue open for a one-line pull request.

Also, it seems a bit verbose to have 4 threads for basically the same overreaching topic:

• #36516
• this issue
• #35754
• #36513
• ...