chore: restrict GitHub workflow permissions - future-proof

[incertum]

See swiftlang/github-workflows#167 for additional context

This approach aligns with security best practices, as detailed in the following documentation:

• https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions
• https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#defining-access-for-the-github_token-scopes
• https://openssf.org/blog/2024/08/12/mitigating-attack-vectors-in-github-workflows/

The default GITHUB_TOKEN permissions are defined at the repository level. This PR modifies the workflow-level overrides to conform to OpenSSF best practices -> defense in depth.

Allow me to quote OpenSSF:
https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

The highest score is awarded when the permissions definitions in each workflow's yaml file are set as read-only at the top level and the required write permissions are declared at the run-level.”

Remediation steps

• Set top-level permissions as read-all or contents: read as described in GitHub's documentation.
• Set any required write permissions at the job-level. Only set the permissions required for that job; do not set permissions: write-all at the job level.

Compare to the LLVM project:

Top-level: contents read, e.g. https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L3-L4 -> this makes it future-proof

Job-level: Allow write permissions as needed, e.g. https://github.com/swiftlang/llvm-project/blob/next/.github/workflows/build-ci-container-windows.yml#L53-L58

[thomasvl]

@Lukasa / @FranzBusch – since this workflow actually drafts a new release for the protoc artifact, does it need something other than read?

[Lukasa]

Oh good catch. @FranzBusch will know better than me.

[FranzBusch]

Yes this needs write permissions according to https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release