verify: exempt gradle-wrapper.jar from in-tree binary check#951
Open
potiuk wants to merge 1 commit into
Open
Conversation
The in-tree binary check scans the whole action repo for pre-compiled native binaries and rejects any without verifiable provenance. It false-flagged `gradle/wrapper/gradle-wrapper.jar` on JetBrains/qodana-action (a node24 action): that jar is Gradle's build wrapper — build-time tooling of the upstream repo, invoked by `./gradlew` during its own build, never executed on a consumer's runner when the action runs — and is itself checksum-verifiable against Gradle's published list (cf. gradle/wrapper-validation-action). Flagging it as opaque action-runtime code is a false positive. Add a path-suffix exemption matched on the canonical `gradle/wrapper/gradle-wrapper.jar` location (not bare name), so a same-named blob dropped elsewhere is still caught, plus a regression test. Generated-by: Claude Opus 4.8 (1M context)
Member
|
Hm, shouldn't projects not add binary executables to their source trees? Making the Gradle build not require the jar to be present is pretty easy to achieve, I've documented a possible approach. TL;DR is:
|
Member
Author
|
I guess it's not something we can "force" on others |
Member
|
True, and it's what I'm going to. Maybe we can tell that it's better to have no executable binaries in the source tree? |
Member
Author
|
Gentle ping @dfoulks1 @ppkarwasz — when you have a moment, this is a small, self-contained fix: it exempts Gradle's build-wrapper jar from the in-tree binary check (with a regression test). It also unblocks #944. Thanks! |
This was referenced Jun 25, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
What
Exempt
gradle/wrapper/gradle-wrapper.jarfrom the in-tree binary check.Why
The in-tree binary check scans the whole action repo for pre-compiled native binaries and rejects any without verifiable provenance. It false-flagged
gradle/wrapper/gradle-wrapper.jaronJetBrains/qodana-action(surfaced while triaging the 2026.1.0 → 2026.1.3 bump in #944).That jar is Gradle's build wrapper — build-time tooling of the upstream repo, invoked by
./gradlewduring its own build, never executed on a consumer's runner when the action runs (qodana-action is anode24action that runsdist/index.js). It is also checksum-verifiable in its own right against Gradle's published list (cf.gradle/wrapper-validation-action). Flagging it as opaque action-runtime code is a false positive.How
_IN_TREE_BINARY_EXEMPT_PATH_SUFFIXES, matched on the canonicalgradle/wrapper/gradle-wrapper.jarpath suffix (not bare name), so a same-named blob dropped anywhere else is still caught.dist/gradle-wrapper.jarstill flagged, generic.jarstill flagged.uv run pytest utils/tests/verify_action_build/test_security.py→ 147 passed. prek clean.Generated-by: Claude Opus 4.8 (1M context)