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
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- build-system, cli
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
[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:
vendorexits 0 withfailed: 0and noverification_parent_chain_unhandledwarning.- 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. 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_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): "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. - Actual:
vendorexits 0 silently, the build fails dependency verification, andvexattestsnot_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: 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.
- Ngôn ngữ chính
- Rust
- Star
- 8
- Fork
- 0
- Merge trung bình
- 15 giờ 39 phút
- Pull request đã merge (30 ngày)
- 104
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của SocketDev/socket-patch
-
agent:triaged bug bughunt pm:cargo priority:p2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
SocketDev/socket-patch#651 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:claimed agent:triaged arch-audit bug pm:hatch priority:p1
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 88/100
SocketDev/socket-patch#613 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:claimed agent:triaged arch-audit bug priority:p3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
SocketDev/socket-patch#571 · 5 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:composer priority:p2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
SocketDev/socket-patch#515 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:npm priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
SocketDev/socket-patch#464 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của SocketDev/socket-patch
Issue tương tự
-
area:release bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
registrystack/registry-stack#1874 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
component:midnight-toolkit status:untriaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
midnightntwrk/midnight-node#2237 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày