Are `read-all` permissions necessary?

[funnelfiasco]

I'm using zizmor to audit GUAC's GitHub workflows and the scorecard workflow reports excessive permissions:

🌈 completed scorecard.yml
warning[excessive-permissions]: overly broad workflow or job-level permissions
  --> .github/workflows/scorecard.yml:18:1
   |
18 | permissions: read-all
   | --------------------- uses read-all permissions
   |
   = note: audit confidence → High

1 findings (0 ignored): 0 unknown, 0 informational, 0 low, 1 medium, 0 high

I don't see anything in this action's docs that explain why read-all is necessary. Does the action require read access to all possible permissions or is that a convenience instead of enumerating the specific permissions required?

If read-all is necessary, I'd be happy to submit a PR to add a mention in the docs.

[spencerschrock]

It is likely a matter of convenience, with a dash of future proofing further updates. The answer is likely different for public vs. private repos as well, and it's something we haven't done a good job of documenting. GitHub has a handy auditing tool for determining least privilege for their REST API, but Scorecard uses the graphQL API which isn't supported by the monitor.

At the very least, this past issue implies contents and actions are useful. Skimming the permission list, I could see a few more being needed depending on the check:

• checks
• issues
• pull-requests
• statuses
  being required in some scenarios.

But certain feature requests means new permissions may be used in the future, such as attestations.

[funnelfiasco]

Thanks for the info. I'll see if the GUAC maintainers are interested in experimenting with me to see if we can identify a minimum level of permissions. If so, I'll contribute that knowledge upstream.

[mattip]

It would be nice to either work with zizmor to tag this warning as inconsequential or fix this in the workflow.

[mattip]

Strangely, I set the permissions to empty {} and the analysis ran https://github.com/numpy/numpy/actions/workflows/scorecards.yml. I am not sure what that means...

[funnelfiasco]

We've been running it on GUAC with a workflow-level contents: read and security-events: write & id-token: write on the analysis job without issue.

[jsoref]

in private repositories, permissions: {} evaluates to

permissions:
  metadata: read

in public repositories, a number of additional permissions are magically available because the repositories are public....

I can't remember what it really means, but it's something like this:

permissions:
  metadata: read
  contents: read
  actions: read
  checks: read

[jsoref]

If people are truly curious, they should try running the action in a private repository with permissions: {} and then slowly give it x: read until it stops complaining.