Bug hunt ledger: Gradle

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Gradle bug-hunt routine (label pm:gradle).

Last updated: 2026-10-01 (run 4), main 2463257 (#277, v5: Gradle 6.8+ vendoring backend), latest release v4.0.0.

Coverage matrix

Hosted (manual snippet). The real CLI prints the snippet against a mock API, and it's pasted into a real build. These cells are from runs 1–2. gradle_snippet is unchanged on 2463257.

OS	Gradle (JDK)	Discovery (scan)	Agent apply	Hosted Groovy direct	Hosted + transitive base	Hosted Kotlin DSL	Hosted + gradle.lockfile	Hosted + verification-metadata	Hosted + version catalog
Linux	6.9.4 (11)	fail #349	fail #349	pass	fail #347	fail #348	fail #396	untested	untested
Linux	7.6.6 (17)	fail #349	fail #349	pass	fail #347	fail #348	fail #396	untested	untested
Linux	8.14.3 (21)	fail #349	fail #349	pass	fail #347	fail #348	fail #396	pass (loud failure)	pass
Linux	9.8.0 (21)	fail #349	fail #349	pass	fail #347	fail #348	fail #396	untested	pass
macOS	6.9.4 / 7.6.6 / 8.14.3 / 9.8.0	untested (OS-independent)	untested	pass (probe)	untested	untested	fail #396	untested	untested
Windows	6.9.4 / 7.6.6 / 8.14.3 / 9.8.0	untested (OS-independent)	untested	pass (probe)	untested	untested	fail #396	untested	untested

Vendored (v5 Gradle backend, new in 2463257). "Shapes" means: Groovy project repos, no settings file, Kotlin DSL, CRLF settings, allprojects, buildSrc, transitive-only. Probes: runs 36821273765 and 36821988108. Run 4 used Linux only.

OS	Gradle (JDK)	Shapes → patched fresh-checkout build	Lock STRICT + verification-metadata	Config cache + tamper	Revert / remove / rollback (LF checkout)	vendor --check on a git checkout	Vendor from a subproject	Mixed pom + gradle	Two patches, drop one	User exclusiveContent in a subproject / buildSrc (incl. pasted hosted snippet)
Linux	6.9.4 (11)	pass (probe)	untested (repo CI capstone)	untested	pass (probe)	pass	untested (path-only, expect #428)	fail #395	untested	untested
Linux	7.6.6 (17)	pass (probe)	untested (repo CI capstone)	untested	pass (probe)	pass	untested	fail #395	untested	untested
Linux	8.14.3 (21)	pass	pass	pass	pass	pass; autocrlf=true clone fails #429	fail #428	fail #395	pass	fail #461
Linux	9.8.0 (21)	pass (local + probe)	pass	pass	pass	pass	fail #428	fail #395	untested	fail #461
macOS	6.9.4 / 7.6.6 / 9.8.0	pass (probe)	untested	untested	pass (probe)	pass	untested	untested	untested	untested (static planner)
Windows	6.9.4 / 7.6.6 / 9.8.0	pass (probe: s1, s9, s12, s14)	untested	untested	fail #429 (script left behind)	fail #429	untested	untested	untested	untested (static planner)

Global (-g), Linux, 8.14.3 cache.

• scan -g report: fail. No Gradle-cached purls (scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349 comment).
• scan -g --mode hosted / --global-prefix --mode hosted refusal: pass (exit 2, no writes).
• -g apply / rollback / vex: blocked (nothing discovered).
• macOS / Windows: untested.

Backlog

1. Maintainer request (partly done): global -g mode. Linux report and refusal are covered. Still to do: macOS / Windows, and apply / rollback / vex through --global-prefix …/modules-2/files-2.1 if that's meant to be supported (see the 20261001T040000Z entry).
2. Kotlin settings.gradle.kts + pluginManagement { includeBuild("build-logic") } convention plugins: is build-logic wired, and are its repositories checked (Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461)?
3. The hosted snippet in its suffixed form, with the dependency bumped, followed by vendor. Check the result and VEX.
4. apply from: 'gradle/repos.gradle' script plugins declaring repositories (a likely Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461 sibling).
5. dependencyResolutionManagement FAIL_ON_PROJECT_REPOS with the hosted snippet; multi-project hosted snippet placement.
6. Re-test Hosted Gradle exclusiveContent snippet is not fail-closed: a transitive request for the base version wins conflict resolution and the unpatched jar is used #347, Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348, scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349, Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395, Hosted Gradle snippet silently builds the unpatched jar in any project using dependency locking (gradle.lockfile), on every Gradle major and OS #396, Vendored Gradle: running vendor from a subproject of a multi-project build exits 0 but wires a nested settings.gradle, so the real build stays unpatched and cd <subproject> && gradle breaks #428, Vendored Gradle: on a Windows (core.autocrlf=true) checkout, vendor --check fails and vendor --revert / remove / rollback leave the settings script behind, because the index and script aren't covered by the -text .gitattributes #429 and Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461 when main moves.

Known non-bugs

• The sandbox can't reach the Socket API. For vendored, use prebuilt_common::prepare_command + a staged manifest/blob (see the run 3 entry). For hosted, use the wiremock shaped like e2e_redirect_maven_build.
• repo.maven.apache.org 429s in the sandbox. Use an init script that rewrites it to repo1.maven.org. JDK 11/17 cells must run on GitHub runners.
• Vendored Gradle: vendor_jvm_upstream_unavailable / verification_metadata_unavailable 404 from the fixture means the m2 seed is missing (junit-bom:5.9.0/5.9.1:module). It's a mock artifact.
• Vendored Gradle intentionally keeps the original GAV, edits only settings files (and buildscript in-block entries), and creates a settings.gradle when none exists. All documented.
• A wrapper below 6.8 is refused (gradle_below_6_8), as documented. 6.8-rc-* parses as 6.8 and is caught by the script's runtime check.
• A vendored project under scan / get --mode hosted keeps its vendored patch (already); there's no takeover. That's safe.
• Gradle build scripts are never edited in hosted mode; the snippet is the documented path.
• VEX never attributes Gradle-pasted hosted snippets (README VEX table). A hosted gradle-only scan --vex ending in manifest_not_found is correct.
• vex has no Gradle product auto-detection (pass --product, or use the git remote), as documented.
• Snippet + verification-metadata.xml fails loudly, which is fail-closed.
• The session's git proxy refuses branch deletes, so probe branches need maintainer cleanup.
• Maven Central (both repo.maven.apache.org and repo1.maven.org) can 429 Gradle in the sandbox. Point mavenCentral at file://<seeded m2> with an init script.
• Dropping one of two vendored Gradle patches (remove <purl>, or a manifest edit + re-vendor) keeps the other wired correctly. Verified in run 4.

[github-actions[bot]]

[agent] 2026-09-30: Gradle bug-hunt run

This is the first run. The ledger was empty and there were no pm:gradle issues to re-triage.

Tested: main f6b7fb9 (CLI 4.0.0), latest release v4.0.0. The Gradle snippet and refusal code isn't in v3.3.0, so v4.0.0 is the first release with it. Gradle 6.9.4 (JDK 11), 7.6.6 (JDK 17), 8.14.3 and 9.8.0 (JDK 21), all on Linux.

Setup: the sandbox can't reach the Socket API. A small Python mock of /v0/orgs/<org>/patches/{batch,by-package,package,view} (shaped like e2e_redirect_maven_build.rs) returns a maven2 override with mavenSuffixedVersion=1.10.0-socket.4d5e6f70. The "Socket repo" is a local file:// maven2 repo that serves a marker-patched commons-text jar and the upstream pom re-versioned to the suffix. The real CLI printed the snippet, and it was pasted verbatim into real Gradle builds.

Cells

• Hosted, Groovy, direct dep only (snippet + bump): pass on 6.9.4 / 7.6.6 / 8.14.3 / 9.8.0.
• Hosted, Groovy, direct + transitive base request (commons-configuration2 2.9.0): fail → Hosted Gradle exclusiveContent snippet is not fail-closed: a transitive request for the base version wins conflict resolution and the unpatched jar is used #347 on all four majors. Conflict resolution picks upstream 1.10.0 with exit 0. A strictly declaration fixes it.
• Hosted, Kotlin DSL: fail → Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348 on all four majors. maven { url "…" } doesn't compile; url = uri("…") does.
• Discovery, Gradle-only project (agent / hosted / vendored scan): fail → scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349. ~/.gradle/caches/modules-2 is never crawled, so the scan reports success with 0 packages.
• Vendored refusal vendor_gradle_unsupported: blocked. Without a warm ~/.m2 the scan never reaches it (scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349). With a warm m2 the mock run stopped at no_local_source, which is a mock artifact (it needs --vendor-source build + blobContent).
• macOS / Windows: not probed. All three findings are OS-independent: Gradle version ordering, snippet text, and the crawler root.

Issues

• Filed Hosted Gradle exclusiveContent snippet is not fail-closed: a transitive request for the base version wins conflict resolution and the unpatched jar is used #347: Hosted Gradle exclusiveContent snippet is not fail-closed: a transitive request for the base version wins conflict resolution and the unpatched jar is used #347
• Filed Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348: Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348
• Filed scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349: scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349

False positives ruled out

• Early "Could not resolve commons-parent:54" failures on 7.6.6 / 9.8.0 were Maven Central HTTP 429 rate limiting. The cells passed on rerun.

Next

1. vendor_gradle_unsupported: prove it fires on a gradle-only project and doesn't fire on a mixed pom + Gradle project (use --vendor-source build + a blobContent mock).
2. Snippet + gradle/verification-metadata.xml (verify-metadata / --write-verification-metadata) and dependency locking (gradle.lockfile, strict mode). Is it loud or silent?
3. Version catalogs (libs.versions.toml) and dependencyResolutionManagement { repositoriesMode = FAIL_ON_PROJECT_REPOS } with the snippet pasted into build.gradle.
4. Mixed pom.xml + build.gradle: does the pom edit plus the snippet both land, and does VEX attest for a Gradle build it can't see?
5. Agent mode with mavenLocal() / --global-prefix pointing at the Gradle cache: what does apply do with the <sha1> directory layout?

[github-actions[bot]]

[agent] 2026-09-30: Gradle bug-hunt run

This is run 2. Tested: main f6b7fb9 (CLI 4.0.0, unchanged since run 1), latest release v4.0.0. Linux sandbox with Gradle 8.14.3 and 9.8.0 (JDK 21). Probe run https://github.com/SocketDev/socket-patch/actions/runs/36791121715 covered ubuntu, macos and windows × Gradle 6.9.4 (JDK 11), 7.6.6 (JDK 17), 8.14.3 and 9.8.0 (JDK 21).

Re-triage: #347, #348 and #349 are still open. Main hasn't moved since they were filed, so there was nothing new to verify and I left no comment.

Mock setup (reusable): the Python mock of /v0/orgs/<org>/patches/{batch,by-package,package,view} from run 1 again. Vendored mode needs the view keyed by the jar member (META-INF/NOTICE.txt) with blobContent, like e2e_vendor_maven_build.rs. With a jar-name key, or without blobContent, the run stops at no_local_source / apply_failed, which are mock artifacts. Discovery still needs a seeded MAVEN_REPO_LOCAL (#349).

Cells

• Vendored, gradle-only: pass. vendor_gradle_unsupported fires and nothing is written.
• Vendored, mixed pom.xml + build.gradle: fail → Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395. Success, no Gradle warning, the Gradle build uses the unpatched jar, and vex attests not_affected (vendored). Maven on the same tree is patched. Reproduced 3×. release/v5-prerelease jvm::detect has the same gap.
• Hosted snippet + dependency locking (default / STRICT / LENIENT): fail → Hosted Gradle snippet silently builds the unpatched jar in any project using dependency locking (gradle.lockfile), on every Gradle major and OS #396 in all 12 OS × Gradle cells. Exit 0 with the upstream jar, because the lock's {strictly 1.10.0} wins. The no-lock control passes in all 12.
• Hosted snippet + verification-metadata.xml (sha256): Gradle 8.14.3 fails loudly ("Dependency verification failed"), so it's fail-closed. Not filed. The snippet could carry the <sha256> entry, but that's UX.
• Hosted snippet + version catalog (bump in libs.versions.toml): pass on 8.14.3 and 9.8.0.
• Hosted gradle-only scan --vex: VEX correctly refuses (manifest_not_found, nothing attested). That VEX never attributes a pasted Gradle snippet is documented (README VEX table: maven "no Gradle").

Issues

• Filed Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395: Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395
• Filed Hosted Gradle snippet silently builds the unpatched jar in any project using dependency locking (gradle.lockfile), on every Gradle major and OS #396: Hosted Gradle snippet silently builds the unpatched jar in any project using dependency locking (gradle.lockfile), on every Gradle major and OS #396

False positives ruled out

• Gradle "BUILD FAILED" during the mixed repro was a Maven Central HTTP 429. It passed on rerun.
• Sandbox curl to Maven Central and Adoptium gets 403/429 from the egress proxy, so JDK 11/17 cells ran on GitHub runners.

Blocked

• The probe branch bughunt/gradle/20260930-lockfile-snippet could not be deleted: git push of the delete got HTTP 403 from the session's git proxy. It only adds .github/workflows/bughunt-gradle.yml. A maintainer should delete it.

Next

1. FAIL_ON_PROJECT_REPOS / PREFER_SETTINGS in settings.gradle dependencyResolutionManagement: where does the pasted snippet go, and is the result loud or silent?
2. Multi-project builds: snippet pasted in a subproject vs root, and allprojects {}.
3. Kotlin DSL + locking and Kotlin DSL + catalogs, once Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348's Kotlin snippet exists.
4. Agent mode on the ~/.gradle/caches/modules-2/files-2.1/<g>/<a>/<v>/<sha1>/ layout via --global-prefix (still blocked by scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349).
5. Re-test Hosted Gradle exclusiveContent snippet is not fail-closed: a transitive request for the base version wins conflict resolution and the unpatched jar is used #347, Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348, scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349, Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395 and Hosted Gradle snippet silently builds the unpatched jar in any project using dependency locking (gradle.lockfile), on every Gradle major and OS #396 when main moves, and check release/v5-prerelease Gradle vendoring.

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Gradle version and on Linux, macOS and Windows.

Where Gradle puts global installs: The Gradle cache (~/.gradle/caches/modules-2, GRADLE_USER_HOME). Note #349 says it's never crawled today; confirm what -g does with it on each OS.

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Gradle package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Gradle project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Gradle version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01: Gradle bug-hunt run

This is run 3. Tested: main 2463257 (#277, the v5 consolidation, which adds a Gradle 6.8+ vendoring backend). The CLI still reports 4.0.0, and the latest release is still v4.0.0. Linux sandbox with Gradle 8.14.3 and 9.8.0 (JDK 21). Probe runs covered ubuntu, macos and windows × Gradle 6.9.4 (JDK 11), 7.6.6 (JDK 17) and 9.8.0 (JDK 21):

• https://github.com/SocketDev/socket-patch/actions/runs/36821273765 (all three OSes)
• https://github.com/SocketDev/socket-patch/actions/runs/36821988108 (windows, unfiltered output)

Harness (reusable): a scratch crates/socket-patch-cli/tests/zz_bughunt_gradle.rs (not committed). It reuses maven_build_common and prebuilt_common::prepare_command (the in-process patch-service fixture that e2e_vendor_jvm_build uses), plus a staged .socket/manifest.json + blob. It runs vendor --json --offline, commits, clones a fresh checkout, runs a real gradle printCp and checks the NOTICE marker. It also has a hosted-mode wiremock (batch / by-package / package / view) copied from e2e_redirect_maven_build. Sandbox notes: repo.maven.apache.org returns 429 here, so I used a GRADLE_USER_HOME/init.d init script that rewrites it to repo1.maven.org. Java needs LC_ALL=C.UTF-8 for unicode paths. On Windows, Rust's Command::new("bash") resolves to WSL's System32 bash.exe, so call git directly.

Re-triage

• Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395 (vendored mixed pom.xml + build.gradle): still reproduces on 8.14.3 and 9.8.0. jvm::detect returns early on any pom.xml, so the new Gradle backend is never reached. Commented with the detail.
• scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349 (Gradle cache never crawled): still reproduces, and scan -g has the same gap. --global-prefix …/modules-2/files-2.1 does parse the Gradle layout. The new design doc states it as a limitation, so I left the triage call to a maintainer (commented).
• Hosted Gradle exclusiveContent snippet is not fail-closed: a transitive request for the base version wins conflict resolution and the unpatched jar is used #347, Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348, Hosted Gradle snippet silently builds the unpatched jar in any project using dependency locking (gradle.lockfile), on every Gradle major and OS #396 (hosted snippet): gradle_snippet (patch/redirect/mod.rs:5843) is unchanged, so not re-run.

Cells (vendored Gradle, new on main)

• Pass on 8.14.3 (Linux), plus 6.9.4 / 7.6.6 / 9.8.0 on ubuntu + macOS through the probe: Groovy project repos; no settings file (one is created); version catalog; Kotlin DSL; CRLF settings with pluginManagement and no trailing newline; buildscript classpath; PREFER_SETTINGS; allprojects repos; transitive-only dep; includeBuild; buildSrc; unicode + space paths; STRICT lock + verification-metadata, online and --offline; configuration cache (tamper invalidates the cache and fails loudly); tamper detection.
• Pass: wrapper 6.7.1 refused with gradle_below_6_8. vendor --check, list, vex (attests when wired; refuses after unwiring or a tampered jar), rollback, remove and repair on LF checkouts.
• Pass (safe): vendored → scan --mode hosted / get --mode hosted keeps the vendored patch (already). The hosted snippet is printed again, but nothing is reverted.
• Fail → Vendored Gradle: running vendor from a subproject of a multi-project build exits 0 but wires a nested settings.gradle, so the real build stays unpatched and cd <subproject> && gradle breaks #428: vendor run from a Gradle subproject exits 0 and writes app/settings.gradle + app/.socket. The root build stays unpatched, cd app && gradle breaks, and VEX attests not_affected. Reproduced on 8.14.3 and 9.8.0.
• Fail → Vendored Gradle: on a Windows (core.autocrlf=true) checkout, vendor --check fails and vendor --revert / remove / rollback leave the settings script behind, because the index and script aren't covered by the -text .gitattributes #429: on a core.autocrlf=true checkout (the Git for Windows default), vendor --check exits 1 and revert / remove / rollback leave .socket/gradle/socket-patch.settings.gradle behind. The index and script are outside the -text .gitattributes. Reproduced on windows-latest × 6.9.4 / 7.6.6 / 9.8.0, and on Linux with -c core.autocrlf=true.
• Global mode (maintainer request, Linux only): scan -g finds no Gradle-cached packages (folded into scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349). scan -g --mode hosted and --global-prefix … --mode hosted refuse with exit 2 and write nothing (pass). I couldn't test -g apply / rollback because Gradle global installs are never discovered.

Issues

• Filed Vendored Gradle: running vendor from a subproject of a multi-project build exits 0 but wires a nested settings.gradle, so the real build stays unpatched and cd <subproject> && gradle breaks #428: Vendored Gradle: running vendor from a subproject of a multi-project build exits 0 but wires a nested settings.gradle, so the real build stays unpatched and cd <subproject> && gradle breaks #428
• Filed Vendored Gradle: on a Windows (core.autocrlf=true) checkout, vendor --check fails and vendor --revert / remove / rollback leave the settings script behind, because the index and script aren't covered by the -text .gitattributes #429: Vendored Gradle: on a Windows (core.autocrlf=true) checkout, vendor --check fails and vendor --revert / remove / rollback leave the settings script behind, because the index and script aren't covered by the -text .gitattributes #429
• Commented on Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395: Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395 (comment)
• Commented on scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349: scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349 (comment)

False positives ruled out

• A verification_metadata_unavailable 404 for junit-bom was a fixture gap: the mock serves only what's seeded in m2, and seeding junit-bom:5.9.0/5.9.1:module fixed it.
• InvalidPathException on a unicode path was the sandbox's default POSIX locale.
• A "fresh clone resolves the unpatched jar" result was two parallel harness tests sharing a work dir. It went away with --exact.
• Missing Windows output in the first probe was a harness bug (WSL bash), not the CLI.
• list with a manifest shows verified: false for a vendored Gradle patch, because the agent-mode file check finds no patched m2 copy. That's informational, not filed.

Blocked

• I couldn't delete the probe branches bughunt/gradle/20261001-v5-vendor-matrix and bughunt/gradle/20261001-windows-crlf, or the older bughunt/gradle/20260930-lockfile-snippet: the git proxy hangs up on delete. Each adds only .github/workflows/bughunt-gradle.yml. A maintainer should delete them.

Next

1. Global -g on macOS / Windows (report-only and refusal), plus --global-prefix on the Gradle cache with apply / rollback, if it is meant to be supported.
2. Two vendored Gradle patches: revert one, keep the other (shared index / script fragments).
3. Hosted snippet pasted by the user (suffixed version) followed by vendor, the hosted → vendored takeover on Gradle.
4. Kotlin DSL settings.gradle.kts + pluginManagement { includeBuild("build-logic") } convention plugins.
5. Re-test Vendored Gradle: running vendor from a subproject of a multi-project build exits 0 but wires a nested settings.gradle, so the real build stays unpatched and cd <subproject> && gradle breaks #428, Vendored Gradle: on a Windows (core.autocrlf=true) checkout, vendor --check fails and vendor --revert / remove / rollback leave the settings script behind, because the index and script aren't covered by the -text .gitattributes #429 and Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395 when main moves.

[github-actions[bot]]

[agent] 2026-10-01: Gradle bug-hunt run

This is run 4. Tested: main 2463257 (unchanged since run 3), latest release v4.0.0. Linux sandbox with Gradle 8.14.3 and 9.8.0 (JDK 21).

Harness: a scratch crates/socket-patch-cli/tests/zz_bughunt_gradle.rs (not committed). It copies the helpers from e2e_vendor_jvm_build.rs and adds a two-patch manifest (commons-text 1.10.0 + commons-lang3 3.12.0, each with a NOTICE marker). New sandbox note: both repo.maven.apache.org and repo1.maven.org returned 429 to Gradle mid-run, so the GRADLE_USER_HOME/init.d init script now rewrites mavenCentral to file://<seeded m2>. With that, Gradle does no network access after the Maven seed.

Re-triage

Main hasn't moved since run 3, which re-checked #349 and #395 on this SHA and filed #428 and #429 against it. I re-ran nothing and changed no issues.

Cells

• Pass: two vendored Gradle patches (backlog item 2), on Linux 8.14.3. vendor applies both, the index has 4 rows, and a fresh checkout resolves both vendored, patched jars.
  • Dropping commons-lang3 with remove <purl>, or by deleting it from the manifest and re-running vendor, removes only its tree and index rows. commons-text stays vendored and patched, and commons-lang3 resolves pristine from the cache. vendor --check exits 0.
  • A full vendor --revert afterwards is byte-exact, apart from the manifest and blob edits I made myself.
• Fail → Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461: a user exclusiveContent rule for the patched group in app/build.gradle, or in a buildSrc precompiled convention plugin, isn't refused. vendor exits 0, then the fresh-checkout build fails with Could not find org.apache.commons:commons-text:1.10.0, and vex attests not_affected.
  • The same happens with the hosted snippet shape (includeVersion base version) pasted into app/build.gradle and then vendor. That covers backlog item 3, the hosted → vendored takeover.
  • Reproduced on 8.14.3 and 9.8.0.
  • Control: the same rule in root allprojects {} / subprojects {} is refused with gradle_exclusive_content_conflict (pass).
• Not run: macOS / Windows probes. The planner is a pure static scan, so the result should be OS-independent, and earlier probe branches still can't be deleted from the session (git proxy), so I didn't add more.

Issues

• Filed Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461: Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461

False positives ruled out

• The root shape (a bare repositories { exclusiveContent } in root build.gradle with no allprojects) failed before vendoring with "no repositories are defined". That was a fixture error, not a CLI bug.
• The 429s from Maven Central were sandbox rate limiting (see the harness note).

Next

1. Global -g on macOS / Windows (maintainer request), plus --global-prefix on the Gradle cache.
2. Kotlin DSL settings.gradle.kts + pluginManagement { includeBuild("build-logic") } convention plugins, including whether build-logic repositories get wired.
3. The hosted snippet in its suffixed form, with the dependency bumped, followed by vendor. Does vendor leave the suffixed declaration resolving from hosted, and what does VEX say?
4. apply from: 'gradle/repos.gradle' script plugins that declare repositories (same blind spot as Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461?).
5. Re-test Hosted Gradle exclusiveContent snippet is not fail-closed: a transitive request for the base version wins conflict resolution and the unpatched jar is used #347, Hosted Gradle snippet is always Groovy DSL, so pasting it into a build.gradle.kts fails to compile #348, scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349, Vendored Maven on a project with both pom.xml and build.gradle reports success with no Gradle warning, the Gradle build keeps the unpatched jar, and VEX attests not_affected #395, Hosted Gradle snippet silently builds the unpatched jar in any project using dependency locking (gradle.lockfile), on every Gradle major and OS #396, Vendored Gradle: running vendor from a subproject of a multi-project build exits 0 but wires a nested settings.gradle, so the real build stays unpatched and cd <subproject> && gradle breaks #428, Vendored Gradle: on a Windows (core.autocrlf=true) checkout, vendor --check fails and vendor --revert / remove / rollback leave the settings script behind, because the index and script aren't covered by the -text .gitattributes #429 and Vendored Gradle: gradle_exclusive_content_conflict refusal doesn't fire for a subproject build script or a buildSrc convention plugin, so vendor exits 0, the build then fails with "Could not find", and VEX attests not_affected #461 when main moves.