Bug hunt ledger: Gradle

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-03 (run 12), main 045d7ec (no Gradle/JVM code changes since 2463257 / #277), latest release v4.0.0. #551 and #349 were re-confirmed on 045d7ec in run 10. Run 8 filed #551, run 9 filed nothing, run 10 filed #620, run 11 filed #656 and commented on #511, and run 12 commented on #620.

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)

Vendored, run 5 cells (Linux).

Gradle (JDK)	.module artifact (jackson-core)	Version catalog	Kotlin settings + includeBuild("build-logic")	Subproject buildscript classpath	apply from: script with exclusiveContent	verify-signatures, pgp-only chain entry	verify-signatures, trusted-keys only	Isolated projects
8.14.3 (21)	pass	pass	pass	pass	fail #461	fail #487	pass	untested
9.8.0 (21)	untested	untested	untested	untested	untested	fail #487	untested	pass
6.9.4 / 7.6.6, macOS, Windows	untested	untested	untested	untested	untested	untested	untested	untested

Vendored, run 6 cells (Linux).

Gradle (JDK)	Range [1.9,1.10.0]	Rich strictly range + prefer	Strict exact 1.10.0!!	1.+ / latest.release	vendor --check on pgp verification-metadata	vendor --revert on pgp verification-metadata
8.14.3 (21)	fail #511	fail #511	pass	unaffected	passes on a broken tree (#487)	pass
9.8.0 (21)	fail #511	fail #511	untested	untested	untested	untested
6.9.4 / 7.6.6, macOS, Windows	untested	untested	untested	untested	untested	untested

Hosted snippet vs settings dependencyResolutionManagement (run 6, Linux, 8.14.3 / 9.8.0). Pasted in build.gradle under FAIL_ON_PROJECT_REPOS / PREFER_SETTINGS / PREFER_PROJECT: loud failure in each mode (fail-closed). Wrapped inside settings DRM repositories: pass.

Vendored, run 7 cells (Linux).

Gradle (JDK)	:tests classifier dep	Kotlin classifier =	IDE sources query	Catalog require range	Range + gradle.lockfile
8.14.3 (21)	fail #533	untested	fail #533	fail #511	pass (lock masks it)
9.8.0 (21)	fail #533	fail #533	untested	untested	untested
6.9.4 / 7.6.6, macOS, Windows	untested	untested	untested	untested	untested

Vendored vs corporate init scripts, run 9 (Linux, 8.14.3, fresh clone).

• Gradle-docs enterprise-repository plugin (removes non-mirror repos): pass (fail-closed, exclusivity survives the removal).
• afterEvaluate { repositories.clear() }: pass (fail-closed). repositories.clear() before the build script: pass (patched).
• Repositories only from init.d (allprojects, settingsEvaluated / beforeSettings → settings DRM): pass (patched).
• Gradle 6 / 7 / 9, macOS, Windows: untested.

Vendored, run 10 cells (Linux).

• .gitignore with *.jar (github Java template), then vendor, commit, fresh clone: fail Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 on 8.14.3 (Groovy) and 9.8.0 (Kotlin). vendor and --check exit 0, the jar is never committed, and the fresh build fails loudly. In the fresh clone, --check and vex correctly refuse.
• Init-script cells (repositories.clear() before / afterEvaluate, enterprise plugin) on 9.8.0: pass, the same as 8.14.3.
• A project path with a space, unicode, %41 and #, on 8.14.3 and 9.8.0: pass.
• Gradle 6 / 7, macOS, Windows: untested.

Vendored, run 11 cells (Linux).

• A stray .DS_Store in the vendored version directory: fail Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656 on 8.14.3 (Groovy) and 9.8.0 (Kotlin). The build fails, and vendor / repair report success without removing the file.
• The vendored jar deleted, then vendor re-run: pass (rebuilt).
• A transitive range from a dependency's POM: fail Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 on 8.14.3 (downgrades to 1.9).
• macOS / Windows, Gradle 6 / 7: untested.

Vendored, run 12 cells (Linux).

• .gitignore with vendor/: fail Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 on 8.14.3. The whole .socket/vendor/ tree, including the index, is never committed, and vendor and --check exit 0.
• Android Studio template with catalog alias(...) plugin ids: the android_or_kmp refusal doesn't fire (vendor exits 0). The build is untested because dl.google.com is blocked. KMP wizard-style (jvm()) with catalog aliases: vendor exits 0, and the fresh build is patched (pass).
• 9.8.0: Kotlin settings + catalog + pluginManagement { includeBuild("build-logic") } + subproject buildscript classpath, fresh clone: pass (all three classpaths patched). vendor --revert: byte-exact (pass).
• macOS / Windows, Gradle 6 / 7: untested.

Agent mode, run 8 (Linux, 8.14.3).

• Gradle-only project (mavenCentral()) with the same GAV in ~/.m2: apply patches m2, vex says not_affected, and the build uses the unpatched cache jar. fail Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551.
• The same with mavenLocal() first (+ -Dmaven.repo.local): pass (control).
• Re-confirmed on bf0e0d1 (run 9), after Fix agent apply writing into shared package stores (#332, #361) #486's shared-store refusal: still fail Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551.
• apply --global-prefix …/modules-2/files-2.1: loud package_not_installed, exit 1 (pass, fail-loud; scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349 layout gap).
• macOS / Windows, Gradle 6 / 7 / 9: untested.

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).
• -g commands run inside a vendored Gradle project leave the project byte-unchanged (pass, run 5, after Fix -g touching the cwd project's state (#436, #445) #446).
• macOS / Windows: untested.

Backlog

1. Android catalog-alias template on a GitHub ubuntu runner (it has the SDK). Vendor bypasses android_or_kmp there (run 12). Build it and file only if AGP fails or resolves the unpatched jar.
2. Maintainer request (partly done): global -g mode. Linux is covered (the report, the refusal, no project leakage, and --global-prefix apply failing loudly). Still to do: macOS / Windows, and apply -g / rollback -g / vex -g with the GAV in ~/.m2 (see the 20261001T040000Z entry).
3. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487, Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511, Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533, Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 and Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe), plus verify-signatures with .module artifacts and imported BOMs.
4. The .module artifact (jackson-core) cell on 9.8.0. It needs a second patch fixture.
5. Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 with catalog strictly / prefer.
6. The hosted snippet in its suffixed form, with the dependency bumped and then vendor. Check the result and VEX. Also the hosted snippet plus a classifier dependency (the hosted analogue of Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533).
7. Agent apply + vex when GRADLE_USER_HOME and ~/.m2 hold different versions (a Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 variant).
8. 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, 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 with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487, Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511, Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533, Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551, Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 and Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656 when vendor/jvm/, maven_crawler.rs or gradle_snippet change.

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.
• A UTF-8 BOM in a Groovy settings.gradle is rejected by Gradle itself; it isn't a valid fixture.
• vex -g attests the cwd project's vendored or hosted state by design (vex.rs:1013).
• Agent-mode Maven patches whole jar files. A manifest keyed by a jar member (the vendored fixture format) fails apply with "File not found", which is a fixture error.
• Under isolated projects, harness init scripts must avoid allprojects; the vendored script itself is IP-compatible on 9.8.0.
• The hosted snippet pasted into build.gradle of a settings-DRM build fails loudly in every repositoriesMode. It works when wrapped inside dependencyResolutionManagement { repositories { … } }. That's placement, not a silent bypass.
• 1.+ / latest.release declarations resolve the newest release before and after vendoring, so a base-version patch correctly doesn't apply. That isn't Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511.
• vendor --revert is byte-exact on a verification-metadata file with pgp entries (run 6).
• A mvn-seeded file:// m2 has no maven-metadata.xml, so range or dynamic-version cells fail before vendoring too. Use real Central for those.
• A gradle.lockfile written before vendoring masks Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511: the range resolves to the locked, vendored version (run 7).
• Gradle's mavenLocal() ignores the MAVEN_REPO_LOCAL env var. It uses -Dmaven.repo.local or settings.xml, so a harness must pass the system property (run 8).
• A repository-stripping corporate init script (the Gradle-docs enterprise plugin, or repositories.clear()) doesn't make vendored Gradle fail open. Gradle keeps the exclusiveContent exclusivity after the vendored repository is removed, so the build fails loudly (run 9).
• In init scripts, compare repository URLs via File.toURI(), not file:// strings: Gradle normalizes file:///x to file:/x/ (run 9 harness note).
• Gradle can throw InvalidPathException on non-ASCII project paths in the sandbox because there's no UTF-8 locale. Export LC_ALL=C.UTF-8 (run 10).
• gradle::wired() accepts the apply line in either settings.gradle or settings.gradle.kts. Gradle reads the Groovy file when both exist, and the planner targets it too, so a mismatch only happens if someone hand-moves the line. That's contrived, so it hasn't been filed (run 10).
• Kotlin DSL harness note: inside build.gradle.kts with the java plugin applied, java.util.… resolves java to the extension. Use a top-level import (run 11).
• A vendored Gradle build failing on a missing vendored file is healed by re-running vendor (rebuilt). Only extra files hit Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656 (run 11).
• android_or_kmp only matches literal plugin ids (gradle.rs:1043), so catalog alias(...) builds aren't refused. On a KMP jvm() build the vendored jar is correctly on the classpath, so that's not filed unless an Android build shows harm (run 12).
• Precompiled build-logic *.gradle.kts scripts hit the same java. extension shadowing as build scripts. Use top-level imports (run 12).

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

[github-actions[bot]]

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

This is run 5. Tested: main 9d718cf, 19 commits past 2463257. None of them touch vendor/jvm/, maven_crawler.rs or gradle_snippet; the Gradle-relevant one is #446, which stops -g from touching the cwd project. 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, deleted afterwards and never committed. It runs one generic scenario: seed the m2 with mvn dependency:get (plus :module), then a pre-vendor build, prebuilt_common::prepare_command plus a staged manifest and blob (any GAV and jar member), vendor --offline, a fresh-checkout build run twice with a patched-marker check on every resolved jar, and finally vex.

• Central still 429s, so GRADLE_USER_HOME/init.d rewrites mavenCentral to file://<m2>.
• systemProp.org.gradle.internal.plugins.portal.url.override=file://<m2>/ in GRADLE_USER_HOME/gradle.properties keeps the implicit plugin portal working offline.
• Under isolated projects, the init script must not use allprojects; beforeSettings alone works.

Re-triage

• 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 still reproduces on 9d718cf (sub shape: vendor exits 0, then the build fails with "Could not find", and VEX reports not_affected). I commented with a new variant: an apply from: 'gradle/repos.gradle' script plugin. 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 (comment)
• 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 still reproduces on 9d718cf (vendor from app/ wires app/settings.gradle, the root build stays unpatched, and VEX reports not_affected). No comment, since I have no new information.

Cells (Linux)

Cell	Gradle	Result
Gradle-module-metadata artifact (jackson-core 2.13.4, .module vendored)	8.14.3	pass (fresh build patched ×2)
Version catalog libs.versions.toml + Kotlin DSL, vendored	8.14.3	pass
Kotlin settings.gradle.kts + pluginManagement { includeBuild("build-logic") }, with build-logic's own classpath using the patched lib and app's classpath via the implicit plugin portal	8.14.3	pass. Both the plugin classpath and app's runtimeClasspath are patched; build-logic/settings.gradle.kts gets the apply line.
Subproject buildscript { classpath … }	8.14.3	pass
apply from: script plugin with exclusiveContent for the group	8.14.3	fail → #461 (comment)
verify-signatures=true (real upstream .asc files, --write-verification-metadata pgp,sha256), with a pgp-only entry for the parent chain (apache-27.pom)	8.14.3, 9.8.0	fail → #487
Same, with a pgp-only entry for the vendored module's own pom	8.14.3	fail → #487
Same, but trusted-keys only (no per-artifact pgp entries in the chain)	8.14.3	pass (the control in #487)
org.gradle.unsafe.isolated-projects=true + settings DRM repos	9.8.0	pass (the script's settings.gradle.beforeProject is accepted)
Settings file ending in a // comment with no EOL	9.8.0	pass
-g, run inside a vendored Gradle project: scan -g, apply -g, rollback -g, scan -g --mode hosted, vex -g	n/a	project files byte-unchanged (#446 holds). scan -g --mode hosted exits 2 as designed.
macOS / Windows	—	not probed (see below)

Issues

• Filed Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487: Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 (vendored Gradle + PGP signature verification: pgp-only entries are kept without a checksum, so the build fails and VEX attests anyway).
• Commented on 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 (the apply from: variant).

False positives ruled out

• A UTF-8 BOM in a Groovy settings.gradle makes Gradle itself fail to compile it ("Unexpected character"), so it isn't a socket-patch shape.
• apply / apply -g failing with "META-INF/NOTICE.txt - File not found" was my fixture's fault: agent-mode Maven patches whole jar files, while the jar-member manifest is the vendored-format fixture.
• vex -g attesting the cwd project's vendored patch is intended: vex.rs:1013 says vex stays rooted at --cwd under --global.
• My first isolated-projects attempt failed in my init script (allprojects is forbidden under IP), not in socket-patch.

Not run

• macOS / Windows probes. The new findings are pure text edits plus OS-independent Gradle verification behaviour, and earlier probe branches still can't be deleted from the session (the git proxy refuses deletes), so I didn't push more.

Next

1. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe), plus verify-signatures with .module artifacts (jackson-core) and imported BOMs.
2. vendor --check and vendor --revert byte-exactness on a verification-metadata file that has pgp entries.
3. Global -g on macOS / Windows (maintainer request), and --global-prefix pointed at the Gradle cache.
4. Hosted snippet in its suffixed form, with the dependency bumped and then vendor.
5. dependencyResolutionManagement with FAIL_ON_PROJECT_REPOS and the hosted snippet; IDE source downloads (the sources classifier) excluded by the vendored exclusiveContent.

[github-actions[bot]]

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

This is run 6. Tested: main 61cfb9b, latest release v4.0.0. The only commit since 9d718cf is an npm crawler fix, so nothing under vendor/jvm/, maven_crawler.rs or gradle_snippet changed. Linux sandbox with Gradle 8.14.3 and 9.8.0 (JDK 21). Maven Central answered 200 this run, so I didn't need the init-script rewrite.

Harness: a scratch tests/zz_bughunt_gradle.rs, deleted afterwards and never committed. It's a thin wrapper that runs the real binary through prebuilt_common::prepare_command with the cwd and args taken from env vars. A shell stage helper writes the manifest and blob for a commons-text 1.10.0 META-INF/NOTICE.txt marker patch.

Re-triage

• Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 still reproduces on 61cfb9b. I commented with new detail: vendor --check returns vendor_check_ok on the broken tree. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 (comment)

Cells (Linux)

Cell	Gradle	Result
vendor --check on verification-metadata with pgp,sha256 entries (verify-signatures)	8.14.3	the check passes, but the build fails (#487, commented)
vendor --revert byte-exactness on that verification-metadata	8.14.3	pass (git status clean)
Range dependency [1.9,1.10.0], vendored	8.14.3, 9.8.0	fail → #511 (resolves 1.9, unpatched; check and VEX still pass)
Rich strictly '[1.9,1.11)'; prefer '1.10.0', vendored	8.14.3, 9.8.0	fail → #511
Strict exact 1.10.0!!, vendored	8.14.3	pass (vendored jar, patched)
1.+ / latest.release, vendored	8.14.3	unaffected (1.15.0 before and after)
Hosted snippet pasted in build.gradle with settings DRM FAIL_ON_PROJECT_REPOS	9.8.0	loud failure ("repository 'maven' was added by build file"), so fail-closed
Same with PREFER_SETTINGS	9.8.0	loud failure (project repo ignored, so the suffixed version isn't found)
Same with PREFER_PROJECT	9.8.0	loud failure (the project block replaces settings repos, so the parent pom is missing)
Hosted snippet wrapped inside settings dependencyResolutionManagement.repositories	8.14.3, 9.8.0	pass (the suffixed jar resolves)

Issues

• Filed Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511: Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511. Vendored Gradle downgrades a version-range dependency to an older unpatched release, because there's no maven-metadata.xml in the vendored repo. Hand-adding one fixes it.
• Commented on Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487.

False positives ruled out

• The DRM + hosted snippet failures are all loud build failures, not silent unpatched builds. The snippet works once it's placed inside settings dependencyResolutionManagement.repositories. That's a placement/usability note, not filed.
• 1.+ / latest.release stay at the newest release (1.15.0), so the 1.10.0 patch correctly doesn't apply.

Not run

• macOS / Windows probes, and Gradle 6.9.4 / 7.6.6. Both findings are OS-independent Gradle resolution behaviour, and the session's git proxy still refuses probe branch deletes.

Next

1. Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 variants: a range in libs.versions.toml (require/prefer/strictly), and a range declared transitively in a dependency's POM. Also check whether a gradle.lockfile that locks 1.10.0 masks it.
2. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 and Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe).
3. Global -g on macOS / Windows (maintainer request), and --global-prefix pointed at the Gradle cache.
4. Hosted snippet in its suffixed form, with the dependency bumped and then vendor (a takeover).
5. IDE sources / javadoc classifier downloads under the vendored exclusiveContent.

[github-actions[bot]]

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

This is run 7. Tested: main 61cfb9b, the same SHA as run 6, so there are no Gradle code changes. Latest release v4.0.0. Linux sandbox with Gradle 8.14.3 and 9.8.0 (downloaded from services.gradle.org), JDK 21.

Harness: the same scratch tests/zz_bughunt_gradle.rs (prebuilt_common::prepare_command, with the cwd and args taken from env vars), deleted afterwards and never committed. A shell stage helper writes the commons-text 1.10.0 META-INF/NOTICE.txt marker manifest and blob. The m2 is seeded with mvn dependency:get, and an init script points mavenCentral at file://<m2>. Range cells need real Central (maven-metadata.xml), and Central 429'd once.

Re-triage

• 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 still reproduces on 61cfb9b (subproject exclusiveContent for org.apache.commons: vendor exits 0, then Could not find commons-text:1.10.0). No new information, so no comment.
• Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511: commented with the catalog and lockfile variants (below). Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 (comment)

Cells (Linux)

Cell	Gradle	Result
testImplementation '…:1.10.0:tests' classifier, vendored, fresh clone	8.14.3, 9.8.0	fail → #533 (build fails, vendor/check/VEX report success)
Kotlin DSL classifier = "tests", vendored	9.8.0	fail → #533, VEX not_affected
IDE sources (ArtifactResolutionQuery + SourcesArtifact)	8.14.3	fail → #533 (sources silently gone after vendoring)
Catalog require = "[1.9,1.10.0]", vendored	8.14.3	fail (#511 variant): 1.10.0 before, 1.9 after
Range + gradle.lockfile locking 1.10.0, vendored	8.14.3	pass (lock masks #511, so the vendored jar is used)
#461 subproject exclusiveContent re-check	8.14.3	fail (still #461)

Issues

• Filed Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533: Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 (vendored Gradle: classifier dependency of the patched GAV, no warning, the build breaks, IDE sources lost; Maven's classifier_declared warning has no Gradle equivalent).
• Commented on Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511.

False positives ruled out

• The first range attempt failed before vendoring too, because a mvn-seeded file repo has no maven-metadata.xml (only maven-metadata-local). That was a harness artifact, so range cells must use real Central.
• A Central 429 on one pre-vendor build was a flake, so I re-ran it from a fresh clone.

Not run

• macOS / Windows probes (Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 and Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 are OS-independent script and resolution behaviour, and the git proxy still refuses probe-branch deletes). Gradle 6.9.4 / 7.6.6.

Next

1. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 / Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 / Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe, if branch cleanup becomes possible).
2. Global -g on macOS / Windows (maintainer request), and --global-prefix pointed at the Gradle cache.
3. A transitive range from a dependency's POM under vendoring (a Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 variant).
4. The hosted snippet in its suffixed form, with the dependency bumped and then vendor (a takeover).
5. The hosted snippet plus a classifier dependency (the hosted analogue of Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533; compare Hosted Maven rewriter ignores <classifier> and suffixes sources/tests/native classifier dependencies, which breaks the build #262 for Maven).

[github-actions[bot]]

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

This is run 8. Tested: main 61cfb9b (unchanged since run 6), latest release v4.0.0. Linux sandbox with Gradle 8.14.3 and JDK 21. The CLI was built --release from main. This run had no scratch Rust harness: the agent-mode record (a whole-jar commons-text-1.10.0.jar key with before/after hashes, plus the blob) was staged with a small python script, and apply / vex ran --offline.

Re-triage

Main hasn't moved since run 7 re-confirmed #461 and #511 on this SHA (and #487 on run 6). I re-ran nothing and changed no issues.

Cells (Linux, 8.14.3)

Cell	Result
Agent apply in a Gradle-only project (mavenCentral()), with the same GAV present in ~/.m2	fail → #551: the m2 jar is patched, exit 0 with applied: 1, vex says not_affected, and Gradle's classpath jar under modules-2 is unpatched
Same, but the build declares mavenLocal(); mavenCentral() (+ -Dmaven.repo.local)	pass (control): Gradle uses the patched m2 jar
apply --offline --global-prefix $GRADLE_USER_HOME/caches/modules-2/files-2.1 (maintainer -g item 4)	loud: package_not_installed, partialFailure, exit 1, cache unchanged. That's correct fail-loud behaviour; the root cause is the #349 layout gap

Issues

• Filed Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551: Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551

False positives ruled out

• The control at first resolved the cache jar even with mavenLocal(). That's because Gradle's mavenLocal() ignores the MAVEN_REPO_LOCAL env var and honours only -Dmaven.repo.local / settings.xml. It was a harness artifact; with -Dmaven.repo.local, the control passes.
• --offline printCp failed once with "No cached version available" for commons-lang3, a partial warm-up from a Central hiccup. Re-ran online.
• rollback reported partial_failure only because the fixture didn't stage the before-blob offline. That's a fixture gap, not filed.

Not run

• macOS / Windows probes (Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 is OS-independent root selection). Gradle 6.9.4 / 7.6.6 / 9.8.0 (only 8.14.3 is preinstalled in this sandbox).

Next

1. Global -g on macOS / Windows (maintainer request): apply -g / rollback -g with the GAV in ~/.m2, plus a Gradle-cached GAV.
2. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 / Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 / Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 / Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe).
3. A transitive range from a dependency's POM under vendoring (a Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 variant).
4. The hosted snippet in its suffixed form, with the dependency bumped and then vendor (a takeover).
5. Agent apply + vex with GRADLE_USER_HOME holding a different version than ~/.m2 (does VEX attest the m2 version?).

[github-actions[bot]]

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

This is run 9. Tested: main bf0e0d1, latest release v4.0.0. Since 61cfb9b main has 21 commits, none in vendor/jvm/, maven_crawler.rs or gradle_snippet. patch/apply.rs gained the #486 shared-store refusal. Linux sandbox with Gradle 8.14.3 and JDK 21, CLI built --release.

Harness: a scratch tests/zz_bughunt_gradle.rs with two tests. bh_stage stages the NOTICE-marker manifest and blob via patched_member. bh_run runs the CLI through prebuilt_common::prepare_command. I deleted it afterwards and never committed it. The m2 was seeded with mvn dependency:get via repo1, including junit-bom 5.9.0/5.9.1. The "corp" repository is file://<m2>.

Re-triage

• Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 still reproduces on bf0e0d1, 2 out of 2 from clean directories: apply succeeds, the m2 jar is patched, vex says not_affected, and the Gradle modules-2 jar is unpatched. Fix agent apply writing into shared package stores (#332, #361) #486's shared-store check doesn't cover it. I commented: Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 (comment)
• No other Gradle-relevant code changed, so I re-ran nothing else.

Cells (Linux, 8.14.3, vendored, fresh clone)

Cell	Result
Control: build repositories { maven corp }	pass (patched)
Gradle-docs "enterprise repository" init plugin (repositories.all { remove repo } unless the URL is the mirror)	pass (fail-closed): socketPatchVendor is removed, but the exclusiveContent filter survives, so Could not find commons-text:1.10.0
Init allprojects { afterEvaluate { repositories.clear(); maven corp } }	pass (fail-closed, same as above)
Init allprojects { repositories.clear(); maven corp } (before build script)	pass (patched; the script re-wires through whenObjectAdded)
Build declares no repositories; init.d supplies them with allprojects	pass (patched)
Same, init.d uses settingsEvaluated → settings DRM repos	pass (patched)
Same, init.d uses beforeSettings → settings DRM repos	pass (patched)
Settings plugins {} (foojay) shape	skipped: covered by planner unit tests (gradle.rs ~2150–2240, 2740)

Issues

• No new issues. Commented on Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551.

False positives ruled out

• The first enterprise-init attempt removed even the mirror, because file:/// and file:/ URL strings differ. That was a harness bug, fixed by comparing against File.toURI().
• Hypothesis: "Gradle vendoring keeps the original GAV, so a mirror/repo-stripping init script fails open." Disproved: removing the vendored repository leaves Gradle's exclusiveContent exclusivity in force, so the build fails loudly.

Not run

• macOS / Windows and Gradle 6 / 7 / 9 probes (probe branches still can't be deleted through the git proxy).

Next

1. Global -g on macOS / Windows (maintainer request).
2. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 / Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 / Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 / Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe).
3. A transitive range from a dependency's POM under vendoring (a Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 variant; needs a hand-written maven-metadata.xml in the file repo).
4. Agent apply + vex with GRADLE_USER_HOME and ~/.m2 holding different versions (a Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 variant).
5. The init-script cells on Gradle 6.9.4 / 9.8.0 (whenObjectAdded and exclusivity semantics across majors).

[github-actions[bot]]

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

This is run 10. Tested: main 045d7ec, latest release v4.0.0. Since bf0e0d1 main has 14 commits. None touch vendor/jvm/, maven_crawler.rs or gradle_snippet. vex.rs now checks every installed copy (#517), which doesn't matter for Gradle because the Gradle cache isn't crawled (#349). Linux sandbox with Gradle 8.14.3 and 9.8.0 (downloaded from services.gradle.org), JDK 21, CLI built --release.

Harness: a scratch tests/zz_bughunt_gradle.rs, as in run 9 (bh_stage / bh_run via prebuilt_common::prepare_command), deleted afterwards and never committed. Agent mode used a hand-staged .socket/manifest.json + blobs (whole-jar files key). Scan used a Python mock of /patch/batch with --proxy-url. The m2 was seeded with mvn dependency:get via repo1, including junit-bom 5.9.0/5.9.1 poms.

Re-triage

• Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 still reproduces on 045d7ec: apply applied: 1, exit 0, vex not_affected, the m2 jar is patched and the Gradle modules-2 jar is not. There's no new information, so I didn't comment.
• scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349 still reproduces: scan --json on a resolved Gradle project → success, scannedPackages: 0.

Cells

Cell	Result
Vendored, .gitignore has *.jar (Java template), 8.14.3 Groovy	fail #620: vendor and --check exit 0, the jar is ignored and never committed, fresh-clone build fails loudly
Same, 9.8.0 Kotlin DSL	fail #620
Fresh clone of the #620 project: vendor --check / vex	pass (exit 1 / vendor_artifact_missing, no false attestation)
9.8.0 init script allprojects { repositories.clear(); maven corp }	pass (patched)
9.8.0 init afterEvaluate { repositories.clear() }	pass (fail-closed)
9.8.0 Gradle-docs enterprise-repository init plugin	pass (fail-closed)
Vendored project in a path with a space, ü, %41 and #, on 8.14.3 and 9.8.0	pass (patched; needs LC_ALL=C.UTF-8 in the sandbox)
Both settings.gradle and settings.gradle.kts present (8.14.3)	Gradle reads the Groovy one, and the planner targets it too (unit test groovy_settings_wins_over_kotlin_like_gradle). Note: gradle::wired() (gradle.rs:637) accepts the apply line in either file, so a line that's only in an unused .kts would count as wired. That's contrived, so I didn't file it.

Issues

• Filed Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620: Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 (plus a README.md:94 comment).
• Handed over to maven (Bug hunt ledger: Maven #318): the same probable gap in .socket/vendor/maven2/.

False positives ruled out

• A Gradle InvalidPathException on the unicode path came from the sandbox's missing UTF-8 locale, not socket-patch.
• Could not parse POM … junit-bom-5.9.0.pom in the local build was a missing m2 seed (a known non-bug).

Not run

• macOS / Windows and Gradle 6 / 7 probes: the git proxy still can't delete probe branches.

Next

1. Global -g on macOS / Windows (maintainer request).
2. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 / Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 / Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 / Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 / Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe).
3. A transitive range from a dependency's POM under vendoring (a Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 variant).
4. Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 variants: a .socket/ ignore, a global core.excludesFile, and **/vendor/ rules.
5. The run 5 cells on 9.8.0 (.module artifact, catalog, includeBuild, subproject buildscript).

[github-actions[bot]]

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

This is run 11. Tested: main 045d7ec (the same SHA as run 10, so no Gradle/JVM code changes), latest release v4.0.0. Linux sandbox with Gradle 8.14.3 (system) and 9.8.0 (from services.gradle.org), JDK 21, CLI built --release.

Harness: a scratch tests/zz_bughunt_gradle.rs (bh_stage / bh_run through prebuilt_common::prepare_command), driven by env vars (BH_PROJ, BH_ARGS), deleted afterwards and never committed. The m2 was seeded with mvn dependency:get via repo1 (commons-text 1.10.0 / 1.9, and the junit-bom 5.9.0 / 5.9.1 poms). An init script points mavenCentral at file://<m2> for exact-version cells, or at repo1.maven.org for the range cell.

Re-triage

• Main is unchanged since run 10, which re-confirmed Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 and scan reports success with 0 packages on a resolved Gradle project because the Gradle cache (~/.gradle/caches/modules-2) is never crawled #349 on 045d7ec. I didn't re-run them or comment.
• Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 has maintainer triage (priority:p3) and the Maven sibling's confirmation of the same root cause. Nothing to add.

Cells

Cell	Result
Vendored, a stray .DS_Store in .socket/vendor/gradle/<g>/<a>/<v>/, 8.14.3 Groovy	fail #656: the build fails ("unindexed files … re-run socket-patch vendor"), vendor re-run says already_vendored and leaves the file, repair is a no-op, --check exits 1, and vex says not_affected
Same, 9.8.0 Kotlin DSL	fail #656
Vendored, the jar deleted from the tree, then vendor re-run	pass (rebuilt)
Vendored, a transitive range [1.9,1.10.0] in a dependency's POM (com.example:lib:1.0 from a file repo), 8.14.3	fail #511 (2 out of 2): before vendoring -> 1.10.0, after vendoring -> 1.9 (unpatched cache jar), vendor gives no warning, --check exits 0, vex says not_affected

Issues

• Filed Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656: Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656
• Commented on Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 (the transitive-POM range variant): Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 (comment)

False positives ruled out

• My first Kotlin probe failed to compile because java.util… inside build.gradle.kts resolves java to the java extension. That was a harness bug; I fixed it with a top-level import java.util.zip.ZipFile.

Not run

• macOS / Windows and Gradle 6 / 7 probes: the git proxy still can't delete probe branches.

Next

1. Global -g on macOS / Windows (maintainer request).
2. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 / Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 / Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 / Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 / Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 / Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe).
3. Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 variants: a .socket/ ignore, a global core.excludesFile, and **/vendor/ rules.
4. The run 5 cells on 9.8.0 (.module artifact, catalog, includeBuild, subproject buildscript).
5. Agent apply + vex when GRADLE_USER_HOME and ~/.m2 hold different versions (a Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 variant).

[github-actions[bot]]

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

This is run 12. Tested: main 045d7ec (the same SHA as runs 10–11, so no Gradle/JVM code changes), latest release v4.0.0. Linux sandbox with Gradle 8.14.3 (system) and 9.8.0 (from services.gradle.org), JDK 21, CLI built --release.

Harness: the same scratch tests/zz_bughunt_gradle.rs (prebuilt_common::prepare_command + a staged manifest/blob, driven by BH_PROJ / BH_ARGS / BH_STAGE), deleted afterwards and never committed. The m2 was seeded with mvn dependency:get through a repo1 mirror. A GRADLE_USER_HOME/init.d script rewrites repo.maven.apache.org to repo1.

Re-triage

• Main is unchanged since run 10, so I re-ran nothing. There are no new human replies on Bug hunt ledger: Gradle #319.

Cells

Cell	Result
android_or_kmp refusal on the current Android Studio template (plugin ids only in libs.versions.toml, alias(libs.plugins.android.application) apply false), 8.14.3	refusal doesn't fire: vendor exits 0 and wires settings.gradle.kts. The control with a literal id("com.android.application") is refused. I couldn't build it: dl.google.com (AGP, SDK) is 403 in the sandbox. Not filed: there's no proven harm (see below)
The same gap on a KMP wizard-style project (alias(libs.plugins.kotlinMultiplatform), Kotlin 2.2.0, jvm() target), 8.14.3	vendor exits 0. The fresh-clone jvmRuntimeClasspath resolves the patched vendored jar (pass in practice)
.gitignore containing vendor/, then vendor, commit, fresh clone, 8.14.3 Groovy (2 out of 2)	fail #620 (a broader variant): all of .socket/vendor/ is ignored, including the index. vendor and --check exit 0. The fresh build fails with "gradle-index.tsv missing", and --check there gives vendor_ledger_missing
9.8.0 Kotlin settings + version catalog + pluginManagement { includeBuild("build-logic") } (convention plugin with commons-text on its classpath) + subproject buildscript classpath (Groovy), fresh clone	pass: app runtimeClasspath, the build-logic plugin classpath and the subproject buildscript classpath are all patched
The same project, vendor --revert	pass: byte-exact against the pre-vendor commit (both settings files restored, .socket/vendor and the script removed)

Issues

• Commented on Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 (the vendor/ rule variant): Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 (comment)
• Filed nothing new.

False positives ruled out

• Catalog-alias Android/KMP refusal bypass: this is real in the code (check_android only matches string literals in root/settings scripts, gradle.rs:1043), but the only buildable case (KMP JVM) comes out correctly patched. Android needs a GitHub runner with the SDK to show any harm. I'll file only if that build fails or silently stays unpatched.
• A java.util… compile error inside a precompiled build-logic .gradle.kts script was the known harness pitfall (use top-level imports).

Not run

• macOS / Windows and Gradle 6 / 7 probes: the git proxy still can't delete probe branches, so I pushed none.

Next

1. Android catalog-alias template vendored build on a GitHub ubuntu runner (has the Android SDK). Does AGP resolve the patched jar, fail, or bypass it? File only on harm. This needs a probe-branch cleanup path.
2. Global -g on macOS / Windows (maintainer request).
3. Vendored Gradle with PGP signature verification exits 0 but breaks the build, because pgp-only verification-metadata entries for the vendored pom and its parent chain are kept without a checksum #487 / Vendored Gradle silently downgrades a version-range dependency to an older unpatched release (1.10.0 → 1.9), because the vendored repository has no maven-metadata.xml; vendor --check and VEX still report it patched #511 / Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear #533 / Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 / Vendored Gradle exits 0 when the project's .gitignore excludes *.jar, so the commit silently drops the patched jar and every fresh checkout fails to build #620 / Vendored Gradle build fails on a stray file such as .DS_Store in the vendored tree, and the fix the error prescribes ("re-run socket-patch vendor") does nothing: vendor says already_vendored and repair is a no-op #656 on Gradle 6.9.4 / 7.6.6 (a JDK 11/17 probe).
4. The .module artifact (jackson-core) cell on 9.8.0. It needs a second patch fixture.
5. Agent apply + vex when GRADLE_USER_HOME and ~/.m2 hold different versions (a Agent-mode apply in a Gradle-only project patches the ~/.m2 copy Gradle never reads, reports success, and VEX attests not_affected while the build uses the unpatched ~/.gradle jar #551 variant).