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

[spencerschrock]

What kind of change does this PR introduce?

bug fix

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

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.

[spencerschrock]

/scdiff generate Binary-Artifacts

[github-actions]

Here's a link to the scdiff run

[loosebazooka]

nice

[faern]

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]

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

scorecard/checks/raw/binary_artifact.go

Lines 203 to 226 in 7b07a8d

	// 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]

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]

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.