use release and tag APIs to enhance imposter commit verification #682
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR does a few things, and is grouped by commit to make review easier. Ignoring the file moves, this PR is closer to
+227 -48
in size, which is hopefully more manageable.bump GitHub library to v65
This is just a simple dependency bump since dependabot doesn't handle Go major versions.
move githubVerifier to its own file
Just a 1:1 movement to keep the files organized
define a commit type
Just switched some arguments to a struct, which isn't too important but helps the next commit which requires storing owner/repo/sha values in a map.
use release and tag APIs to enhance imposter commit verification
The old verification process assumed a commit was always in the default
branch, or came from a select number of hardcoded release branches. This
was error prone whenever new releases branches were used by some of the
actions we check. (see ossf/scorecard-action#1367 (comment))
The commit verification workflow now uses dynamic data to determine
which branches to check. The steps are now:
the most common case.
the hardcoded checks and should require fewer updates in the future.
Note
github/codeql-action
required some special logic as their releases are all tagged from main, even though the tags come from different release branches. Handling this required parsing GitHub action semantic versions, which I used golang.org/x/mod/semver for.Both of these assumptions currently match the versioning used by the codeql-action, so the fact that this is a
go.mod
parsing package shouldn't matter (but feel free to comment if you disagree).