Binary Artifact detection gradle-wrapper.jar Incorrect logic

[anantshri]

This is hilarious bug, took me a few tries to get to the exact issue.

1. gradle-wrapper.jar is detected as a binary-artifact
2. suggested recommendation is to do a wrapper validation Binary Artifacts should allow well-known artifacts, if best practices are followed #1815
3. even with wrapper validation script there was error

The issue gets closed only when following conditions are met.

1. gradle/wrapper-validation-action@v<version_number> is specified
2. The configuration is in an independent file.

The issue is not closed in following conditions.
2. Config is in part of other files
3. gradle/wrapper-validation-action@<hash> is specified : Hash pinning which is the recommended action by scorecard and gets raised if my action doesnt have hashes is raised and if we fix that binary artifact issue reappears

I am no golang expert but if i am looking at the right file then there is a very specific @v condition check in this code.

https://github.com/ossf/scorecard/blob/main/checks/raw/binary_artifact.go#L36

[naveensrinivasan]

Thanks, @anantshri. Would you like to send a PR to solve this issue?

[anantshri]

Like i said not good at programming. wont want to commit on doing something which i dont understand.
Thats why i waited to raise the bug to ensure I have checked as many conditions as possible.

[big-andy-coates]

Also affecting all my Gradle based repos. :'(

I don't think its as simple as removing the v from the regex as there is also a Gradle version check, which would require resolving the version hash to a semantic version number. The fix is therefore beyond my Go knowledge.

https://github.com/ossf/scorecard/blob/main/checks/raw/binary_artifact.go#L37

[AdamKorcz]

Is the solution here to verify that it is a digest after the @?

[spencerschrock]

Is the solution here to verify that it is a digest after the @?

The issue is the regex accepts a version or commit SHA:

`^gradle\/wrapper-validation-action@v?(.+)$`

But the later on we always try to parse it as a version. This check was added here, but I don't see the significance of it.

I think it was this comment:

is it enough to have the gradle validation action or must it be the "latest version" of the action (is this too expensive to calculate?)

[AdamKorcz]

What is the expected behaviour? Ie: Should the check pass with either version or digest?

[anantshri]

Ideally it should only pass with digest coz overall guidance is not to have version tags. but if we want to be atomic in nature then it should pass for both version or digest. As there is another check which fails if it sees version tags.