Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues 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

Ouverte
  • Quelque chose ne va pas ?
#487 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
java, rust
Domaine
build-system, cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
15 h 39 min
PR mergées (30 j)
104

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.