Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: `gem "x", "~> 2.0"` becomes the older patched `"1.0.0"`, and a gem the project never declared is appended as a new dependency

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#1,125 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

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ó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
75/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
ruby, rust
Lĩnh vực
cli

Hướng nghiên cứu

Kiểm tra crates/socket-patch-core/src/patch/redirect/mod.rs gần các dòng 6098–6445. Guard tại dòng 6205 bị bỏ qua khi locked là None; thêm một kiểm tra để các dự án không khóa bỏ qua pinning hoặc việc thêm gems. Xác thực với các fixtures của e2e_redirect_gem_build.rs rằng thao tác quét chỉ Gemfile để lại manifest không thay đổi.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

agent:triaged bug bughunt pm:bundler priority:p1

[agent] Found by the scheduled Bundler (RubyGems) bug-hunt routine (ledger #316).

Summary

#1060 (the fix for #1055) skips a crawled gem version that the project's lock doesn't resolve (redirect_gem_version_not_locked). The check only runs when a lock exists, though: let locked = files.get(lock_name).map(...) is None for a project with a Gemfile / gems.rb and no Gemfile.lock / gems.locked, and if let Some(specs) = &locked then skips the guard completely. Library repos usually don't commit their lock, so this is the normal state of a fresh clone before bundle install.

In that state, a hosted scan on a machine whose shared gem home holds another project's copy of a patched gem does what #1055 described, and adds one more failure:

  1. The constraint is overwritten. gem "vuln-gem", "~> 2.0" is rewritten to source "<patch registry>" do gem "vuln-gem", "1.0.0" end. The next bundle install installs 1.0.0, where the untouched Gemfile installs 2.0.0.
  2. An unrelated gem is added. A Gemfile that never mentions vuln-gem (gem "tiny-dep" only) gets a new source … do gem "vuln-gem", "1.0.0" end block appended through the "genuinely undeclared (a transitive dep)" branch. The next bundle install adds vuln-gem (= 1.0.0)! to the project's dependencies. Without the scan the project installs only tiny-dep.

Both runs exit 0 and report redirected: 1 / action: "pinned". The only warning is redirect_gem_stale_install about the shared-home copy, which doesn't say that the project's declared dependencies changed. rollback / remove can't undo it either: a Gemfile-only pin isn't a reference without a lock (CLI_CONTRACT.md "Lockless pins"), so the user has to edit the Gemfile by hand.

Impact

  • The project's dependencies change silently: it downgrades below the user's constraint, or it picks up a gem it never used.
  • With --vex, the scan exits 1 because of the stale warning, but plain scan --mode hosted / CI runs exit 0 and leave the rewritten Gemfile for the user to commit.

Repro (real Bundler; hermetic mock upstream + patch registry, the e2e_redirect_gem_build.rs fixtures)

# upstream mock serves tiny-dep 1.0.0 and vuln-gem 1.0.0 + 2.0.0; the patch registry serves patched vuln-gem 1.0.0
export GEM_HOME=$TMP/shared-home GEM_PATH=$TMP/shared-home:<system gem dir>
# project A (another project on the same machine) puts vuln-gem 1.0.0 into the shared home
(cd a && printf 'source "<upstream>"\ngem "vuln-gem", "1.0.0"\n' > Gemfile && bundle install)

# project B: fresh clone, Gemfile only, no lock
cd b && printf 'source "<upstream>"\n\ngem "vuln-gem", "~> 2.0"\n' > Gemfile
socket-patch scan --mode hosted --json --yes --api-url <mock> --org test-org --api-token fake
#   exit 0, redirect.patches = [{purl: pkg:gem/[email protected], action: pinned}]
cat Gemfile
#   source "<upstream>"
#   source "<patch registry>/" do
#     gem "vuln-gem", "1.0.0"
#   end
bundle install    # → Gemfile.lock: vuln-gem (1.0.0) / DEPENDENCIES vuln-gem (= 1.0.0)!
# control: the same Gemfile without the scan → "Installing vuln-gem 2.0.0"

# project C: Gemfile declares only `gem "tiny-dep"`, no lock
socket-patch scan --mode hosted …   # exit 0; appends `source "<patch registry>" do gem "vuln-gem", "1.0.0" end`
bundle install    # DEPENDENCIES gains `vuln-gem (= 1.0.0)!`; the control installs only tiny-dep

Expected vs actual

  • Expected (CLI_CONTRACT.md, redirect_gem_version_not_locked): hosted mode "re-points the version the lock resolves; it never picks a version", and "the user's declared constraint and the locked version are never overwritten". With no lock there's nothing resolved to re-point. The scan should skip these gems with a warning (the way cargo refuses a lockless project with redirect_cargo_lockless_dependents), or at least never append a gem the manifest doesn't declare and never replace a declared requirement that the crawled version doesn't satisfy.
  • Actual: the crawled shared-home version is pinned as an exact top-level requirement in both shapes, and the scan reports success.

Matrix

OS Ruby Bundler Shape Result
Linux 3.3.6 2.5.22 lockless ~> 2.0 declaration fails (downgrade to 1.0.0)
Linux 3.3.6 2.5.22 lockless, gem not declared fails (gem appended and installed)
Linux 3.3.6 4.0.18 both shapes fails (same, CHECKSUMS lock written by the install)
Linux 3.3.6 4.0.18 same shapes with a lock (the #1055 control) pass (redirect_gem_version_not_locked, repo e2e suite)
macOS / Windows — — — untested; the logic is OS-independent

Main b96a785, which includes #1060. Both shapes were reproduced twice, on two Bundler versions. I didn't bisect: the lockless path is outside the #1060 change, so this predates it.

Suspect code

  • crates/socket-patch-core/src/patch/redirect/mod.rs:6098: locked is None without a lock.
  • crates/socket-patch-core/src/patch/redirect/mod.rs:6205: if let Some(specs) = &locked, so the #1055 guard is skipped when there's no lock.
  • crates/socket-patch-core/src/patch/redirect/mod.rs:6387 (in-place rewrite to the exact version) and :6445 (the "genuinely undeclared (a transitive dep): append a block" branch, which without a lock can't tell a transitive dep from an unrelated shared-home gem).

No probe runs: found and confirmed on Linux only.

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)
257

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.