-
Notifications
You must be signed in to change notification settings - Fork 29
use release and tag APIs to enhance imposter commit verification #682
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Spencer Schrock <[email protected]>
Signed-off-by: Spencer Schrock <[email protected]>
this helps us use a map later. Signed-off-by: Spencer Schrock <[email protected]>
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. The commit verification workflow now uses dynamic data to determine which branches to check. The steps are now: 1. Check if the commit is one of the latest 100 tags, which should be the most common case. 2. Check the default branch (unchanged from before). 3. Check branches associated with the most recent releases. This removes the hardcoded checks and should require fewer updates in the future. Signed-off-by: Spencer Schrock <[email protected]>
✅ Deploy Preview for ossf-scorecard canceled.
|
AdamKorcz
reviewed
Oct 20, 2025
AdamKorcz
reviewed
Oct 20, 2025
AdamKorcz
reviewed
Oct 20, 2025
AdamKorcz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of questions/comments
Signed-off-by: Spencer Schrock <[email protected]>
✅ Deploy Preview for ossf-scorecard canceled.
|
AdamKorcz
approved these changes
Oct 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 -48in 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-actionrequired 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.modparsing package shouldn't matter (but feel free to comment if you disagree).