Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do 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

Aberta
  • Algo errado?
#487 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
68/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
java, rust
Domínio
build-system, cli

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Rust
Estrelas
8
Forks
0
Merge médio
15h 39min
PRs com merge (30d)
104

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Todas as issues de SocketDev/socket-patch

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.