[agent] Found by the scheduled Gradle bug-hunt routine (ledger #319).
Summary
When gradle/verification-metadata.xml has <verify-signatures>true</verify-signatures>, Gradle serves the vendored module's pom and its parent chain through the socketPatchVendor repository. Those are attributed to socketPatchVendor in the verification report even when the parent isn't in the vendored tree. That repository has no .asc files, so for each of those poms Gradle falls back to checksum verification.
vendor adds sha256 entries for components that are missing from the file. It keeps an existing <artifact> entry unchanged when that entry holds only a <pgp value=…/>, which is what --write-verification-metadata pgp,sha256 writes for any key that isn't grouped under <trusted-keys>. The result:
vendor exits 0 with failed: 0 and no verification_parent_chain_unhandled warning.- Every build of the vendored checkout then fails with
Dependency verification failed … apache-27.pom (org.apache:apache:27) from repository socketPatchVendor, Signature file is missing / Checksums are missing from verification metadata.
vex attests not_affected.
The same thing happens to the vendored module's own pom when its component already exists with pgp-only entries. The jar entry is rewritten to a sha256 (correct), but the pom's <pgp> entry is kept, so that pom fails as well.
Impact
Vendoring breaks every build of a project that uses Gradle's signature verification, which is the hardened setup Gradle recommends. The failure is loud, so no unpatched jar ships. But CI goes red right after a "successful" vendor, the error looks like a compromised dependency, and the VEX document attests a fix for a build that can't run.
Repro
I used the repo's vendored-JVM fixture: prebuilt_common::prepare_command plus a staged .socket/manifest.json and blob for pkg:maven/org.apache.commons/commons-text@1.10.0 (a NOTICE marker patch), the same as e2e_vendor_jvm_build::gradle_multi_project_…. Maven Central was a local file:// mirror holding the real Central jars, poms and .asc files, so the signatures are the real upstream ones.
cat > settings.gradle <<'EOF'
rootProject.name='sv'
EOF
cat > build.gradle <<'EOF'
plugins { id 'java' }
repositories { mavenCentral() }
dependencies { implementation 'org.apache.commons:commons-text:1.10.0' }
tasks.register('printCp') { def rc = configurations.runtimeClasspath
doLast { rc.files.each { println 'SOCKET-CP ' + it } } }
EOF
gradle --write-verification-metadata pgp,sha256 --export-keys printCp
# verification-metadata.xml: verify-signatures=true, trusted-key 2DB4F1EF… for group org.apache.commons,
# and <component org.apache:apache:27><artifact apache-27.pom><pgp value="84789D24…"/></artifact>
gradle printCp # control: exit 0 (Central jar)
# stage manifest + blob, then:
socket-patch vendor --json --offline # exit 0, applied 1, failed 0, no warnings
# adds sha256 (origin="socket-patch") for commons-text jar+pom, commons-parent-54.pom, junit-bom 5.9.0/5.9.1;
# leaves apache-27.pom as pgp-only
# fresh checkout of the committed files (no manifest/blobs):
gradle printCp
# > Dependency verification failed for configuration ':runtimeClasspath'
# One artifact failed verification: apache-27.pom (org.apache:apache:27) from repository socketPatchVendor
# report: "Signature file is missing", "Checksums are missing from verification metadata"
socket-patch vex --offline --product pkg:maven/x/y@1 # exit 0, "status": "not_affected"If I add a single <sha256 value="$(sha256sum apache-27.pom)"/> next to the existing <pgp> in the vendored checkout, the build passes and resolves the vendored, patched jar. So the missing checksum is the whole problem.
Variant (own pom). I narrowed the org.apache.commons trusted key to commons-lang3 / commons-parent, and gave commons-text:1.10.0 a component with <pgp> entries for both its jar and its pom (the control build passes). After vendor, the jar entry becomes a sha256, but the pom keeps <pgp> only. The build fails with 2 artifacts failed verification: apache-27.pom … commons-text-1.10.0.pom (org.apache.commons:commons-text:1.10.0) from repository socketPatchVendor.
Expected vs actual
- Expected:
docs/design/maven-vendoring.md (Gradle): "When gradle/verification-metadata.xml already exists, vendoring updates the patched jar's checksum and, when metadata verification is enabled, adds missing POM and module entries for the artifact, its parents and imported BOMs … Existing verification policy and unrelated checksums are kept." A vendored checkout should build against an existing verification file. If it can't, vendor should refuse or warn, as it already does with verification_parent_chain_unhandled. A <pgp>-only entry can't verify anything served from socketPatchVendor, which has no signatures. For the vendored pom, the module and every parent or BOM pom in their chain, a pgp-only artifact entry should count as "missing a checksum" and get a sha256 added next to the <pgp>, keeping the user's entry.
- Actual:
vendor exits 0 silently, the build fails dependency verification, and vex attests not_affected.
Matrix
| OS |
Gradle (JDK) |
parent pgp-only (apache-27) |
own pom pgp-only |
control (no vendor) |
trusted-keys only, no pgp entries for chain |
| Linux |
8.14.3 (21) |
fail (2/2 builds) |
fail (2/2) |
pass |
pass (commons-parent-54 gets a sha256) |
| Linux |
9.8.0 (21) |
fail (2/2) |
not run |
pass |
pass |
| macOS / Windows, 6.9.4 / 7.6.6 |
— |
not run. The planner is a pure text edit and Gradle's signature fallback is OS-independent, so I expect the same |
|
|
|
First bad version: main 2463257 (#277), which introduced Gradle vendoring. v4.0.0 refused Gradle-only vendoring (vendor_gradle_unsupported). Tested on main 9d718cf.
Suspect code
crates/socket-patch-core/src/vendor/jvm/gradle.rs:1656-1657: in update_verification_component, with metadata_extension set (the pom / module / parent / BOM entries), an existing <artifact> is returned unchanged (return Ok((as_, ae, text[as_..ae].to_string()))) whatever it contains.gradle.rs:1636-1688: when the patched component exists, only the jar entry is replaced or inserted. The pom (and .module) artifact entries of that component are left as they are, including pgp-only ones.gradle.rs:1481 (unverified_parent_chain) treats any existing <component> as "listed", so no warning is emitted either.
[agent] Found by the scheduled Gradle bug-hunt routine (ledger #319).
Summary
When
gradle/verification-metadata.xmlhas<verify-signatures>true</verify-signatures>, Gradle serves the vendored module's pom and its parent chain through thesocketPatchVendorrepository. Those are attributed tosocketPatchVendorin the verification report even when the parent isn't in the vendored tree. That repository has no.ascfiles, so for each of those poms Gradle falls back to checksum verification.vendoraddssha256entries for components that are missing from the file. It keeps an existing<artifact>entry unchanged when that entry holds only a<pgp value=…/>, which is what--write-verification-metadata pgp,sha256writes for any key that isn't grouped under<trusted-keys>. The result:vendorexits 0 withfailed: 0and noverification_parent_chain_unhandledwarning.Dependency verification failed … apache-27.pom (org.apache:apache:27) from repository socketPatchVendor,Signature file is missing/Checksums are missing from verification metadata.vexattestsnot_affected.The same thing happens to the vendored module's own pom when its component already exists with pgp-only entries. The jar entry is rewritten to a
sha256(correct), but the pom's<pgp>entry is kept, so that pom fails as well.Impact
Vendoring breaks every build of a project that uses Gradle's signature verification, which is the hardened setup Gradle recommends. The failure is loud, so no unpatched jar ships. But CI goes red right after a "successful"
vendor, the error looks like a compromised dependency, and the VEX document attests a fix for a build that can't run.Repro
I used the repo's vendored-JVM fixture:
prebuilt_common::prepare_commandplus a staged.socket/manifest.jsonand blob forpkg:maven/org.apache.commons/commons-text@1.10.0(a NOTICE marker patch), the same ase2e_vendor_jvm_build::gradle_multi_project_…. Maven Central was a localfile://mirror holding the real Central jars, poms and.ascfiles, so the signatures are the real upstream ones.If I add a single
<sha256 value="$(sha256sum apache-27.pom)"/>next to the existing<pgp>in the vendored checkout, the build passes and resolves the vendored, patched jar. So the missing checksum is the whole problem.Variant (own pom). I narrowed the
org.apache.commonstrusted key tocommons-lang3/commons-parent, and gavecommons-text:1.10.0a component with<pgp>entries for both its jar and its pom (the control build passes). Aftervendor, the jar entry becomes asha256, but the pom keeps<pgp>only. The build fails with2 artifacts failed verification: apache-27.pom … commons-text-1.10.0.pom (org.apache.commons:commons-text:1.10.0) from repository socketPatchVendor.Expected vs actual
docs/design/maven-vendoring.md(Gradle): "Whengradle/verification-metadata.xmlalready exists, vendoring updates the patched jar's checksum and, when metadata verification is enabled, adds missing POM and module entries for the artifact, its parents and imported BOMs … Existing verification policy and unrelated checksums are kept." A vendored checkout should build against an existing verification file. If it can't,vendorshould refuse or warn, as it already does withverification_parent_chain_unhandled. A<pgp>-only entry can't verify anything served fromsocketPatchVendor, which has no signatures. For the vendored pom, the module and every parent or BOM pom in their chain, a pgp-only artifact entry should count as "missing a checksum" and get asha256added next to the<pgp>, keeping the user's entry.vendorexits 0 silently, the build fails dependency verification, andvexattestsnot_affected.Matrix
First bad version: main
2463257(#277), which introduced Gradle vendoring. v4.0.0 refused Gradle-only vendoring (vendor_gradle_unsupported). Tested on main9d718cf.Suspect code
crates/socket-patch-core/src/vendor/jvm/gradle.rs:1656-1657: inupdate_verification_component, withmetadata_extensionset (the pom / module / parent / BOM entries), an existing<artifact>is returned unchanged (return Ok((as_, ae, text[as_..ae].to_string()))) whatever it contains.gradle.rs:1636-1688: when the patched component exists, only the jar entry is replaced or inserted. The pom (and.module) artifact entries of that component are left as they are, including pgp-only ones.gradle.rs:1481(unverified_parent_chain) treats any existing<component>as "listed", so no warning is emitted either.