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 `rollback` / `remove` strip the DEPENDENCIES `!` when the user's `source … do` block opens after a `;` on the same line, so frozen installs fail on Bundler 4.0.19+

Đã đóng
  • Có gì không ổn?
#1,531 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

Một pull request liên quan đã được merge.

  • #1537 của @mikolalysenko — đã merge

Đá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
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
ruby, rust
Lĩnh vực
backend

Hướng nghiên cứu

Start in crates/socket-patch-core/src/patch/redirect/upstream/gem.rs around lines 627-637 (block_stack), where source_pending is only set from a leading source on a line. Reproduce with the e2e test gem_hosted_unwind_keeps_a_source_block_bang in crates/socket-patch-cli/tests/e2e_redirect_gem_build.rs using the ; fixture, and check in_source_block returns true for the ; shape. Done when the restored lock keeps the ! and the frozen install exits 0 on Bundler 4.0.19+.

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

This is a neighbour of #1056 / #1476 / #1509, still open on main after #1520. The hosted unwind (rollback / remove) decides whether a restored gem gets its ! source pin in Gemfile.lock DEPENDENCIES by asking in_source_block. The block scanner only recognises a source statement at the start of a line. A source "…" do that follows another statement and a ; on the same line is read as a plain do block:

source "https://rubygems.org"

zz = 1; source "https://rubygems.org" do
  gem "vuln-gem", "1.0.0"
end

Bundler evaluates this as a source block and locks vuln-gem (= 1.0.0)!. After scan --mode hosted → bundle install → rollback (or remove <purl>), socket-patch restores the Gemfile byte for byte but writes vuln-gem (= 1.0.0) without the !. On Bundler 4.0.19+ the next frozen install (BUNDLE_FROZEN=true / deployment / CI) fails with exit 16 ("Your lockfile needs to be updated, but it can't be because frozen mode is set"). 4.0.18 and older only warn.

Impact

After an unwind the project's lock no longer matches what Bundler derives from the Gemfile, so every frozen CI or deploy install fails until someone runs an unfrozen bundle install by hand. The ; spelling isn't common, but it's legal Ruby, and things like git_source(:gh) { … }; source "…" do show up in generated Gemfiles. Nothing gets silently unpatched: this is a broken-lock bug, not a security bypass.

Repro

This uses the repo's own harness. In crates/socket-patch-cli/tests/e2e_redirect_gem_build.rs, change the Driver::ScanVexSourceBlockMultiLineOpener fixture body to the ; shape and run the existing capstone:

         Driver::ScanVexSourceBlockMultiLineOpener => format!(
-            "source \"{up}/upstream\"\n\nsource(\n  \"{up}/upstream\"\n) do\n  \
+            "source \"{up}/upstream\"\n\nzz = 1; source \"{up}/upstream\" do\n  \
              gem \"{DEP}\", \"{DEP_VERSION}\"\nend\n",

gem install bundler -v 4.0.23
BUNDLER_VERSION=4.0.23 SOCKET_PATCH_BUNDLER_E2E_VERSION=4.0.23 SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1 \
  cargo test --release -p socket-patch-cli --test e2e_redirect_gem_build \
  gem_hosted_unwind_keeps_a_source_block_bang -- --include-ignored --nocapture

Output:

assertion `left == right` failed: rollback: the lock comes back byte for byte, `!` included
  left:  "…DEPENDENCIES\n  vuln-gem (= 1.0.0)\n…"
  right: "…DEPENDENCIES\n  vuln-gem (= 1.0.0)!\n…"

With the lock assertion relaxed, the fresh-checkout BUNDLE_FROZEN=true bundle install exits 16 for both rollback and remove. In the same run, the plain, assignment (#1476) and brace (#1509) fixtures restore the ! and their frozen installs exit 0.

A unit probe of in_source_block agrees: in_source_block("x = 1; source \"https://x\" do\n gem \"rails\"\nend\n", at gem) returns false. The other 52 shapes I probed (\-continued do, a brace block nested in group, heredocs, %w(end), for … do end, CRLF, …) all return the expected answer.

Expected vs actual

  • Expected: CLI_CONTRACT.md / docs/ecosystems.md ("Hosted unwind coverage") say rollback / remove restore the upstream lock, and the #1056 fix restores a source-block gem's ! pin "whichever URL the block names". The restored pair should pass a frozen install, as it does for the line-leading source … do form.
  • Actual: the ! is dropped, and frozen installs fail on Bundler 4.0.19+.

Matrix

OS Ruby Bundler zz = 1; source … do → rollback → remove Line-leading source … do (control)
Linux 3.3.6 4.0.23 fail (! dropped, frozen exit 16; ×2) fail (exit 16) pass
Linux 3.3.6 ≤ 4.0.18 ! dropped; Bundler only warns (exit 0), as in #1509 same pass
macOS / Windows — — not run (OS-independent text scan)

Suspect code

crates/socket-patch-core/src/patch/redirect/upstream/gem.rs:627-637 (block_stack): source_pending is set only from masked.strip_prefix("source") at the start of a line. In the masked.split(';') loop, every statement after the first gets source_pending = false and is never checked for a leading source. Deciding source_pending per ;-statement (at depth 0) should fix it.

Tested on main a8da202. I didn't run a probe branch, because the scan is pure text.

Ngôn ngữ chính
Rust
Star
8
Fork
1
Merge trung bình
16 giờ 18 phút
Pull request đã merge (30 ngày)
587

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.