Build scripts and wrapper JARs

Check C14 · execution surface family · severity HIGH · automatic · one of the 22 checks

The question this check asks: does this repository carry build-time code that your editor or build tool will run before you have read it — a Rust build script, a checked-in build-tool binary, a CMake configure step, a test-collection hook?

Why it matters

Opening a Rust repository in an editor runs its build.rs: rust-analyzer's own documentation states that proc macros and build scripts are executed by default. Gradle and Maven wrappers are checked-in JAR files that ./gradlew and ./mvnw execute on every build — binaries you did not compile, in a place nobody reads, and two weaponised ones were found in the MinecraftOnline project. CMake's execute_process() runs at configure time, and the CMake Tools extension can configure on open. And pytest executes conftest.py during collection, before a single test runs. Each of these is ordinary engineering; each is also a place where code runs without a decision from you.

How RepoGates scores it

C14 reads the repository's file list — one API call, no clone — and fires on five paths. Three at severity HIGH for 10 points: build.rs (“rust-analyzer runs build scripts on open”), gradle/wrapper/gradle-wrapper.jar (“checked-in JAR executed by ./gradlew”) and .mvn/wrapper/maven-wrapper.jar (the same for ./mvnw). Two at MEDIUM for 5 points: CMakeLists.txt (“execute_process at configure time”) and conftest.py (“executed at pytest collection”). A repository that trips one HIGH scores 90, one MEDIUM 95; the badge stays green, the verdict is REVIEW, and the default personal policy warns. Nothing here blocks on its own. The execution-surface evidence note in the scoring table:

“28.8% of top-100 repos carry devcontainers — informative, not damning”

False positives we know about

Every Rust crate with a build script, every Gradle and Maven project (the wrapper is the recommended way to ship one), every CMake project, every Python project with shared test fixtures. That is most of four ecosystems, which is why the weights are 10 and 5 and the action is a warning. The finding is a reminder of what will run when you open the folder; the settings below decide whether it does.

What this check does not cover

It sees names, not contents: a build.rs that generates bindings and one that downloads a payload are the same line here, and a genuine Gradle wrapper and a replaced one have the same path. Verifying the wrapper's checksum needs the bytes; a deep scan reads them. Other build systems — Makefiles, npm scripts, Bazel — are not on the list; setup.py has its own check. And the finding fires at download time; the build runs when you open or build the project.

And RepoGates as a whole gates browser downloads only — it does not see git clone, package managers, curl, or fetches made by AI agents outside the browser.

Check it yourself

Without installing anything: look at the repository root for build.rs, CMakeLists.txt and conftest.py, and under gradle/wrapper/ and .mvn/wrapper/ for a JAR. With the GitHub CLI:

gh api repos/OWNER/REPO/git/trees/HEAD?recursive=1 --jq '.tree[].path' | grep -E '^(build\.rs|CMakeLists\.txt|conftest\.py)$|wrapper\.jar$'

Then turn the automatic execution off in your user settings — rust-analyzer.cargo.buildScripts.enable: false, rust-analyzer.procMacro.enable: false, cmake.configureOnOpen: false — and, for a wrapper JAR, compare its checksum with Gradle's published list before the first ./gradlew:

shasum -a 256 gradle/wrapper/gradle-wrapper.jar   # compare with services.gradle.org/versions/all

Questions

Every Rust crate has a build.rs — does every one warn? Every one with a build.rs at the root, yes: 10 points and a warning, never a block. rust-analyzer's own documentation says build scripts and proc macros run by default, so opening the folder in an editor is running the file. The warning tells you that before the download; two user settings — rust-analyzer.cargo.buildScripts.enable and rust-analyzer.procMacro.enable set to false — make the warning moot for your machine.

What is wrong with a Gradle wrapper? Nothing, when it is the wrapper Gradle published. It is a binary JAR committed to source that ./gradlew executes on every build, so a replaced one runs whatever it likes on every developer's machine — two weaponised wrappers were found in the MinecraftOnline project. Verify the JAR's checksum against Gradle's published list, or use GitHub's wrapper-validation action in CI.

Does RepoGates stop git clone? No. RepoGates gates browser-initiated downloads — Download ZIP and release-asset archives. It does not see git clone, package managers, curl, or fetches made by AI agents outside the browser. It reads the file list before the download; the build runs when you open or build the project.

Related checks

C15 Committed binaries — the wrapper JAR is one; so is anything else you cannot rebuild · C13 Editor and workspace config — the editor running things on trust · C16 Install scripts — code that runs at install rather than at build.

Add RepoGates to Chrome Pricing

Numbers on this page: rust-analyzer documentation and the Gradle wrapper attack report as cited in the repository vetting standard; weights and actions from the product's scoring and policy tables.