scorecard icon indicating copy to clipboard operation
scorecard copied to clipboard

⚠️ Warn and not fail if job perms are content:write

Open eddie-knight opened this issue 1 year ago • 4 comments

Following discussion in #2338, it has been determined that the permissions check should no longer deduct when a job is set to write. This code is a minimalist change, and will require additional polish/cleanup of obsolete logic later.

Signed-off-by: Eddie Knight [email protected]

What kind of change does this PR introduce?

Changes how scoring is done for token permissions

What is the current behavior?

The Token-Permissions check is opinionated regarding job-level permissions.

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

The Token-Permissions check now will only issue a warning regarding job-level permissions.

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

Which issue(s) this PR fixes

Fixes #2338

Special notes for your reviewer

I wasn't able to get the Token-Permissions check to report anything lower than 10/10 when running locally, even for repos that are less than 10 when checked via the API. As such, my validation checks were limited. I suggest a regular contributor or maintainer validates these changes before merging.

Does this PR introduce a user-facing change?

Job Level Permissions will no longer be evaluated on the Scorecard, but warnings will still be issued.

eddie-knight avatar Oct 14 '22 19:10 eddie-knight

If we want to warn on write permissions, but not affect scoring if defined at the run level, this might be better addressed in the scoring code. Curious what others think. Various unit tests (make unit-test) check the number of debug, vs info, vs warn messages. Regardless of approach, some of the unit-tests will need changed as the expected scores will change.

https://github.com/ossf/scorecard/blob/36d6a340ed9fcc5d5a894c722cca9526a9a4e40a/checks/evaluation/permissions.go#L191

The various calls to permissionIsPresent could be replaced with permissionIsPresentInTopLevel for example.

spencerschrock avatar Oct 14 '22 19:10 spencerschrock

Thanks @spencerschrock, I think it's a good idea to shift the change into the calculate function instead.

eddie-knight avatar Oct 14 '22 20:10 eddie-knight

Integration tests success for [3e127da170dea283ba7e0e5de4f4dc8f4b40a2fe] (https://github.com/ossf/scorecard/actions/runs/3253012126)

github-actions[bot] avatar Oct 14 '22 21:10 github-actions[bot]

Codecov Report

Merging #2355 (72d9e4e) into main (78c7e83) will not change coverage. The diff coverage is 0.00%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2355   +/-   ##
=======================================
  Coverage   40.55%   40.55%           
=======================================
  Files         112      112           
  Lines        8822     8822           
=======================================
  Hits         3578     3578           
  Misses       4984     4984           
  Partials      260      260           

codecov[bot] avatar Oct 14 '22 22:10 codecov[bot]

Integration tests success for [72d9e4e84bc8e5c7c4a0b88d96452a51ad461af7] (https://github.com/ossf/scorecard/actions/runs/3267248107)

github-actions[bot] avatar Oct 17 '22 17:10 github-actions[bot]

Thanks @spencerschrock! I raised packages as a suggestion for discussion on #2338 so we can make a PR for that as well if there is agreement

eddie-knight avatar Oct 17 '22 18:10 eddie-knight