🐛 Forgive job-level permissions

[pnacht]

What kind of change does this PR introduce?

Job-level write permissions are no longer penalized.

• PR title follows the guidelines defined in our pull request documentation

What is the current behavior?

Currently, high-risk permissions (contents/packages/actions: write) are not penalized when set at job-level. However, low-risk permissions (everything else) are penalized wherever they appear (top- or job-level).

What is the new behavior (if this is a feature change)?**

As per the discussion in #2338, all permissions are allowed if set at job-level.

• Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

Fixes #3045

Special notes for your reviewer

Does this PR introduce a user-facing change?

For user-facing changes, please add a concise, human-readable release note to
the release-note

(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

Job-level permissions are no longer penalized.

[spencerschrock]

Thanks for the PR.

1. Can you update the documentation along with this scoring change?
2. Linter is complaining about dead code, so permissionIsPresent will need removed.
3. Can we add a test to evaluate "job level write permissions not penalized" or something like that? Something that has:

    permissions:
      statuses: write
      checks: write
      security-events: write
      deployments: write
      contents: write
      packages: write
      actions: write

[pnacht]

Done!

[codecov]

Codecov Report

Merging #3162 (a68162e) into main (96b2169) will decrease coverage by 6.10%.
The diff coverage is 100.00%.

❗ Current head a68162e differs from pull request most recent head 59d9429. Consider uploading reports for the commit 59d9429 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3162      +/-   ##
==========================================
- Coverage   71.77%   65.67%   -6.10%     
==========================================
  Files         168      170       +2     
  Lines       12907    12860      -47     
==========================================
- Hits         9264     8446     -818     
- Misses       3122     3957     +835     
+ Partials      521      457      -64     

[Gby56]

Thanks a lot for this, noticed the bug/noise today, definitely the checks: write is a chicken and egg scenario, maybe if the granularity was at a step-level we could consider it, but for the whole job, that's too much.

Maybe this should be brought to Github's attention, the fundamental problem is that the action is reporting itself the check OK or not OK, so we give it the token with the permission, meaning a malicious actor could force all checks to be OK and merge ? Shouldn't the runner or some wrapper around that, check the step/job final output and decide on the check status ?

[github-actions]

Stale pull request message

[pnacht]

@spencerschrock, is there anything else I can do on this PR? The failed test doesn't seem related, as far as I can tell.

[spencerschrock]

Thanks. Just one final documentation bit I missed before.