ci: Set most GITHUB_TOKEN permissions back to defaults

[danielhjacobs]

Should match https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token and these permissions, except for id-token:

[danielhjacobs]

Fix for #17322

[torokati44]

Does it really need this many write permissions just to produce attestations? 🤔

[danielhjacobs]

I don't know what it needs. These are the default permissions granted by a repo with a permissive access policy, and until 3 days ago, these are what we used. These are still the permissions being used by every other job in this workflow aside from these web jobs.

[danielhjacobs]

See also my latest message in the meta-discussion channel on Discord.

[torokati44]

Hmm: actions/deploy-pages#329 (comment)

[torokati44]

Just based on plain logic and common sense:

What do you think about trying something like this?

      actions: read
      attestations: write
      checks: read
      contents: none
      deployments: none
      discussions: none
      id-token: write
      issues: none
      metadata: read
      packages: none
      pages: none
      pull-requests: read
      repository-projects: none
      security-events: none
      statuses: write

[danielhjacobs]

contents: read appears in the example for npm provenance, so it might be necessary: https://docs.npmjs.com/generating-provenance-statements#example-github-actions-workflow. Not sure though, as they don't say it's necessary.

I can try those. The annoying part is that I can't test this stuff easily, so we just need to test it live.

[danielhjacobs]

contents: none is below the default restricted access: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

[torokati44]

Let's make content to read then?

The annoying part is that I can't test this stuff easily, so we just need to test it live.

That's fine I guess, one missed nightly is not the end of the world. And it may even work out fine!

[danielhjacobs]

Pushed these changes. We may also want to look into setting default access to restricted if we want to restrict access levels for this token.

[torokati44]

I mean, let's see...! What's the worst that could happen?!

[danielhjacobs]

It's broken already and it's reduced permissions compared to what it used to be (except for id-token, but provenance requires that). So let's try it.

[torokati44]

Huh...?

Invalid workflow file: .github/workflows/release_nightly.yml#L318
The workflow is not valid. .github/workflows/release_nightly.yml (Line: 318, Col: 7): Unexpected value 'metadata'

[danielhjacobs]

metadata is apparently set without being explicitly set as it was set yesterday.

I'm away from my computer but you can try removing that key/value.

[torokati44]

And now we have:

HTTP 403: Resource not accessible by integration (https://uploads.github.com/repos/ruffle-rs/ruffle/releases/171776832/assets?label=&name=ruffle-nightly-2024_08_24-reproducible-source.zip)

[torokati44]

Apparently we need contents: write.
https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token#overview
How, and why, releases are "contents" is weird to me. I assumed it was strictly about what git itself manages.