Vendored Gradle exits 0 with no warning on a classifier dependency of the patched module, then the build fails with "Could not find …-tests.jar" and IDE sources silently disappear
Maintainer thường phản hồi trong vòng 1 ngà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
- 52/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá 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 with crates/socket-patch-core/src/vendor/jvm/gradle.rs around lines 119-120 and 157-158, then compare the classifier handling in maven_reactor.rs:983-988 and the generated filter in socket-patch.settings.gradle:49-52. Run the supplied Gradle classifier and sources reproductions to observe the silent success. Done means unsupported classifier declarations no longer pass as successful without the documented warning or refusal, with the relevant checks covered.
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
The generated Gradle script claims the patched coordinates with exclusiveContent { … includeVersion(g, a, v) } (crates/socket-patch-core/src/vendor/jvm/socket-patch.settings.gradle:51). That claim covers every artifact of g:a:v, including classifier variants (tests, sources, javadoc, …), but the vendored repo only holds the main jar and pom. So once a project is vendored:
- A declared classifier dependency (
testImplementation 'org.apache.commons:commons-text:1.10.0:tests', or Kotlinclassifier = "tests") can't be resolved, and the build fails withCould not find commons-text-1.10.0-tests.jar … Searched in .socket/vendor/gradle/…. - IDE-style sources resolution (
ArtifactResolutionQuery…SourcesArtifact, which is what IntelliJ / Eclipse sync use) silently returns no sources for the patched module. Before vendoring it returnedcommons-text-1.10.0-sources.jar.
vendor still exits 0 with status: success and no warning. vendor --check returns vendor_check_ok, and vex attests not_affected / inline_mitigations_already_exist.
The Maven backend already handles this: maven_reactor.rs:983 warns classifier_declared ("a classifier variant of … bypasses the pin"), and docs/design/maven-vendoring.md lists classifier artifacts as unsupported scope. The Gradle planner has no equivalent check. gradle.rs only runs check_android and check_exclusive_content on build files (gradle.rs:119-120, 157-158), so the unsupported declaration goes through without a warning or a refusal.
Impact
A repo that uses a tests-classifier artifact of a patched library stops building once the vendored commit lands, even though vendor, check and VEX all report success. Every IDE user also silently loses source attachment for the patched module.
Repro (Linux, Gradle 8.14.3 and 9.8.0, main 61cfb9b)
mkdir c1 && cd c1 && git init -q
echo "rootProject.name = 'c1'" > settings.gradle
cat > build.gradle <<'EOF'
plugins { id 'java' }
repositories { mavenCentral() }
dependencies {
implementation 'org.apache.commons:commons-text:1.10.0'
testImplementation 'org.apache.commons:commons-text:1.10.0:tests'
}
tasks.register('cp') { doLast { configurations.testRuntimeClasspath.files.each { println "CP " + it } } }
EOF
gradle -q cp # OK: commons-text-1.10.0.jar, commons-text-1.10.0-tests.jar, commons-lang3
git add -A && git commit -qm init
# stage .socket/manifest.json + blob for a pkg:maven/org.apache.commons/[email protected] patch
socket-patch vendor --json # exit 0, status success, no warnings
git add -A && git commit -qm vendored && git clone -q . ../fresh
gradle -q -p ../fresh cp
# > Could not find commons-text-1.10.0-tests.jar (org.apache.commons:commons-text:1.10.0).
# Searched in the following locations:
# file:/…/.socket/vendor/gradle/org/apache/commons/commons-text/1.10.0/commons-text-1.10.0-tests.jar
socket-patch vendor --check --json # vendor_check_ok, exit 0
Sources check (add to build.gradle, then run gradle -q src):
tasks.register('src') { doLast {
def ids = configurations.runtimeClasspath.incoming.resolutionResult.allComponents.collect { it.id }.findAll { it instanceof ModuleComponentIdentifier }
def r = dependencies.createArtifactResolutionQuery().forComponents(ids).withArtifacts(JvmLibrary, SourcesArtifact).execute()
r.resolvedComponents.each { c -> c.getArtifacts(SourcesArtifact).each { a -> println "SRC ${c.id} -> ${a instanceof ResolvedArtifactResult ? a.file.name : a.failure}" } }
} }
Before vendoring it prints SRC org.apache.commons:commons-text:1.10.0 -> commons-text-1.10.0-sources.jar. After vendoring it prints nothing.
The patch data came from the repo's own fixture path (prebuilt_common::prepare_command plus a staged manifest and blob for a META-INF/NOTICE.txt marker patch, the same as e2e_vendor_jvm_build.rs).
Expected vs actual
- Expected: docs/design/maven-vendoring.md says classifier artifacts are not enabled in this release, and that for unsupported declarations "the backend does not silently claim those unsupported declarations are patched." So
vendorshould warn or refuse (like Maven'sclassifier_declared) when a build file declares a classifier of the patched GAV. Alternatively, the exclusive filter or the vendored repo should still let classifier artifacts resolve upstream. - Actual: exit 0, no warning, a broken build, lost IDE sources,
vendor_check_ok, and VEXnot_affected.
Matrix
| OS | Gradle | DSL | Result |
|---|---|---|---|
| Linux | 8.14.3 (JDK 21) | Groovy :tests |
fail (×2: original tree and fresh clone) |
| Linux | 9.8.0 (JDK 21) | Groovy :tests |
fail (fresh clone) |
| Linux | 9.8.0 (JDK 21) | Kotlin classifier = "tests" |
fail, VEX not_affected |
| Linux | 8.14.3 | sources via ArtifactResolutionQuery | fail (silently empty) |
| macOS / Windows | — | — | untested. The behaviour comes from the OS-independent script and Gradle resolution |
The Gradle backend is new in v5 (2463257), so there's no earlier good release.
Suspect code
crates/socket-patch-core/src/vendor/jvm/socket-patch.settings.gradle:49-52:exclusiveContentwithincludeVersionclaims every classifier of the GAV.crates/socket-patch-core/src/vendor/jvm/gradle.rs:119-120/157-158: no classifier-declaration warning to matchmaven_reactor.rs:983-988.
- Ngôn ngữ chính
- Rust
- Star
- 8
- Fork
- 0
- Merge trung bình
- 1 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 211
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
-
arch-audit refactor
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
SocketDev/socket-patch#1011 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged arch-audit bug priority:p3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
SocketDev/socket-patch#982 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Hosted yarn classic pins give no berry-migration warning, so a yarn 2+ install silently drops them (vendored warns about the same trap)Có thể đã có người làm @mikolalysenko đã nhận 1 ngày trước. Đang mởagent:claimed agent:triaged bug bughunt pm:yarn-classic priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
SocketDev/socket-patch#907 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:bundler priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
SocketDev/socket-patch#896 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
SocketDev/socket-patch#783 · 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ự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Markdown Preview Fonts Don't Show Selected OptionCó thể đã có người làm @RadhiRasho đã nhận hôm nay. Đang mởstate:needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 61/100
zed-industries/zed#65300 · 1 bình luận ·
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 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Add collect method to DataFrameĐang mởenhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/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 82/100
Maintainer thường phản hồi trong vòng 1 ngày