Configure permissions of GITHUB_TOKEN
in workflows
#4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GITHUB_TOKEN
is an access token provided automatically by GitHub Actions. The default permissions of this token for workflow runs in a trusted context (i.e., not triggered by a PR from a fork) are set in the enterprise/organization/repository's administrative settings, giving it either read-only or write permissions in all scopes.In the case of a read-only default configuration, any workflow operations that require write permissions would fail with an error like:
https://github.com/arduino/ArduinoCore-renesas/actions/runs/5354302514/jobs/9711176308#step:9:46
https://github.com/arduino/ArduinoCore-renesas/actions/runs/5354680503/jobs/9712023980#step:3:7
In the case of a write default configuration, workflows have unnecessary permissions, which violates the security principle of least privilege.
For this reason, GitHub Actions now allows fine grained control of the permissions provided to the token, which are used here to configure the workflows for only the permissions they require in each job.
The automatic permissions downgrade from write to read for workflows triggered by events generated by a PR from a fork is unaffected.
Even when all permissions are withheld (
permissions: {}
), the token still provides the authenticated API request rate limiting allowance, which is a common use of the token in these workflows.Read permissions are required in the
contents
scope in order to checkout private repositories. Even though those permissions are not required for this public repository, the standardized "Sync Labels" workflow template is intended to be applicable in public and private repositories both and so a small excess in permissions was chosen in order to use the upstream template unmodified.Here are demonstration runs in my fork of the workflows with the changes proposed here: