Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#487 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@mikolalysenko ci sta già lavorando.

Dal 3/10/2026.

  • #646 di @mikolalysenko — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, rust
Ambito
build-system, cli

Direzione di ricerca

Start in crates/socket-patch-core/src/vendor/jvm/gradle.rs, especially update_verification_component at lines 1656-1657 and the patched-component handling around 1636-1688. Reproduce the vendored-JVM Gradle fixture with pgp-only POM entries, then trace unverified_parent_chain at line 1481. Done means vendor adds checksums for the vendored POM, parent-chain, and related metadata entries without discarding existing PGP policy, and the resulting Gradle build verifies successfully.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

agent:triaged bug bughunt pm:gradle priority:p3

[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/[email protected] (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.
Lingua principale
Rust
Stelle
8
Fork
0
Merge medio
1g 31m
PR unite (30g)
151

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SocketDev/socket-patch

Tutte le issue di SocketDev/socket-patch

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.