Skip to content
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

🐛 Support renamed gradle verification action and callers which pin to hash #4097

Merged
merged 2 commits into from
May 9, 2024

Conversation

spencerschrock
Copy link
Member

What kind of change does this PR introduce?

bug fix

What is the current behavior?

gradle/wrapper-validation-action must be present and pinned to a hash

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

  • detects gradle/actions/wrapper-validation
    • From gradle/wrapper-validation-action's readme: "As of v3 this action has been superceded by gradle/actions/wrapper-validation"
  • Also support actions pinned to a hash.
  • Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

Fixes #2477
Fixes #2357

Related to ossf/scorecard-action#782 (comment), but requires a release (which was going to be cut today anyway)

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.)

Binary-Artifacts check now supports the new gradle wrapper validation action, and can be pinned to a hash.

From gradle/wrapper-validation-action's readme:
"As of v3 this action has been superceded by
gradle/actions/wrapper-validation"

Also support actions pinned to a hash.

Signed-off-by: Spencer Schrock <sschrock@google.com>
@spencerschrock spencerschrock requested a review from a team as a code owner May 9, 2024 17:55
@spencerschrock spencerschrock requested review from justaugustus and raghavkaul and removed request for a team May 9, 2024 17:55
@spencerschrock
Copy link
Member Author

/scdiff generate Binary-Artifacts

Copy link

github-actions bot commented May 9, 2024

Signed-off-by: Spencer Schrock <sschrock@google.com>
@spencerschrock spencerschrock enabled auto-merge (squash) May 9, 2024 18:20
@spencerschrock spencerschrock merged commit 7ce8609 into ossf:main May 9, 2024
36 checks passed
@spencerschrock spencerschrock deleted the gradle-verify-name-update branch May 9, 2024 18:27
@loosebazooka
Copy link
Contributor

nice

@faern
Copy link

faern commented Sep 24, 2024

This fix does not seem to work for us.

We merged the CI workflow for gradle/actions/wrapper-validation back on August 29: https://github.com/mullvad/mullvadvpn-app/blob/2b0bd13088a1417ac6510746051043bf81dfc8c7/.github/workflows/android-validate-gradle-wrapper.yml. But the scorecard still warns us about Warn: binary detected: android/gradle/wrapper/gradle-wrapper.jar:1, which can be seen here: https://securityscorecards.dev/viewer/?uri=github.com/mullvad/mullvadvpn-app

Are we using the gradle/actions/wrapper-validation workflow wrong, or is this check faulty in some way?

@spencerschrock
Copy link
Member Author

Are we using the gradle/actions/wrapper-validation workflow wrong, or is this check faulty in some way?

You're not using it wrong, the check (currently) assumes gradle/actions/wrapper-validation runs on every commit, where as you filtered the workflow so it only runs when it's needed (when the gradle-wrapper.jar changes).

// If validated, check that latest commit has a relevant successful run
runs, err := c.ListSuccessfulWorkflowRuns(gradleWrapperValidatingWorkflowFile)
if err != nil {
// some clients, such as the local file client, don't support this feature
// claim unvalidated, so that other parts of the check can still be used.
if errors.Is(err, clients.ErrUnsupportedFeature) {
return false, nil
}
return false, fmt.Errorf("failure listing workflow runs: %w", err)
}
commits, err := c.ListCommits()
if err != nil {
return false, fmt.Errorf("failure listing commits: %w", err)
}
if len(commits) < 1 || len(runs) < 1 {
return false, nil
}
for _, r := range runs {
if *r.HeadSHA == commits[0].SHA {
// Commit has corresponding successful run!
return true, nil
}
}

@faern
Copy link

faern commented Sep 25, 2024

Thanks for the quick response! Maybe our trigger rules are not optimal. I realize someone could potentially commit a malicious gradle-wrapper.jar without our CI noticing if they commit it to another path, or push it without a PR (branch protection rules would not allow that, but anyway).

But I also don't want to run it on every single commit (since gradle-wrapper.jar virtually never changes, it's a waste of CI minutes).

I'm thinking to change the trigger rule to something like:

on:
  push:
    paths:
      - .github/workflows/android-validate-gradle-wrapper.yml
      - '**/gradle-wrapper.jar'

This seems like it would be secure. I think scorecard should be made to allow this at least. But maybe it should indeed deny our current setup, since it has flaws. I can create a separate issue for this. But I have not yet verified if scorecard would warn on my new on:-setup.

@spencerschrock
Copy link
Member Author

This seems like it would be secure. I think scorecard should be made to allow this at least. But maybe it should indeed deny our current setup, since it has flaws. I can create a separate issue for this. But I have not yet verified if scorecard would warn on my new on:-setup.

Your new trigger sounds good, and following the intention of the Binary-Artifact check, even if Scorecard has trouble giving credit for this due to some implementation limitations.

We do our analysis on the tarball produced from git archive, so we don't have the gradle-wrapper revision easily accessible to check against.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
4 participants