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

Gem hosted `rollback` / `remove` turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes

Đã đóng
  • Có gì không ổn?
#457 3 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ó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
78/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, testing

Hướng nghiên cứu

Read crates/socket-patch-core/src/patch/redirect/mod.rs:5070 and crates/socket-patch-core/src/patch/redirect/upstream/gem.rs:480,691, then run provably_transitive_needs_a_blank_line_before_the_block. Reproduce rollback and remove with an LF-terminated Gemfile and CHECKSUMS lock; done means both restore the Gemfile and lock byte-identically without creating a direct dependency, while existing blank-line behavior remains covered.

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

Mô tả

agent:claimed agent:triaged bug bughunt pm:bundler priority:p1

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

Summary

When scan --mode hosted redirects a transitive gem, it appends a source "<patch registry>" do … end block to the end of the Gemfile. When the Gemfile already ends in a newline (the normal case), it writes no blank separator line. The upstream restore that rollback and remove share only treats a block as "the rewriter's append for a transitive gem" (Decl::Transitive) when a blank line precedes the block (provably_appended). Because the rewriter's own append never has one, the restore falls through to Decl::Direct. The transitive gem comes back as a new top-level declaration, gem "<name>", "<version>", and the lock gains a DEPENDENCIES entry <name> (= <version>).

This only affects converged locks, which means locks with a CHECKSUMS section (Bundler 2.6+ with checksums enabled, the Bundler 4 default). CHECKSUMS-less locks take the mixed-state path, which reads DEPENDENCIES and gets this right.

Impact

  • After rollback / remove, the project is not back on its upstream registry state, which is what CLI_CONTRACT.md's "Hosted unwind coverage" promises. It has a new direct dependency pinned to exactly the version that had the vulnerability.
  • That pin freezes the vulnerable version. In the repro, bundle update rack keeps rack 3.2.1 after the rollback, while the byte-identical control upgrades to rack 3.2.7. A user who removes the hosted patch to take the upstream fix can't get it until they find and delete a declaration they never wrote.
  • It's silent: status: success, reverted: [pkg:gem/[email protected]], no warning.

Repro (Linux, Ruby 3.3.6, Bundler 4.0.17; real rubygems.org upstream, local mock for the patch API and the patch-registry compact index)

# Project: rack 3.2.1 is transitive via rackup; the Gemfile ends with a declaration line + "\n".
printf 'source "https://rubygems.org"\n\ngem "rackup", "2.2.1"\n' > Gemfile
bundle config set --local path vendor/bundle
bundle install                       # Bundler 4 writes CHECKSUMS
cp Gemfile Gemfile.pristine; cp Gemfile.lock lock.pristine; rm -rf vendor
socket-patch scan --mode hosted --json --yes --api-url $API --org test-org --api-token fake
#   -> redirected 1, rewrittenFiles [Gemfile, Gemfile.lock]; block appended right after `gem "rackup"` (no blank line)
socket-patch rollback --json --yes --patch-server-url $API --api-url $API --org test-org --api-token fake
#   -> status success, hosted.reverted [pkg:gem/[email protected]]
diff Gemfile.pristine Gemfile
#   3a4
#   > gem "rack", "3.2.1"
diff lock.pristine Gemfile.lock
#   12a13
#   >   rack (= 3.2.1)
bundle update rack && grep '    rack (' Gemfile.lock   # rack (3.2.1): stuck on the vulnerable version

Control: the same flow with the Gemfile ending in \n\n (one trailing blank line) restores byte-identically (Gemfile and lock), and bundle update rack moves to 3.2.7.
socket-patch remove pkg:gem/[email protected] gives the same result as rollback.

Expected vs actual

  • Expected (CLI_CONTRACT.md, "Hosted unwind coverage", gem bullet): "the spec moves back into the upstream GEM section …, the source "<patch registry>" do … end block is undone … and the DEPENDENCIES pin loses its !". For a gem the rewriter appended because it was transitive, the code's own intent (Decl::Transitive: "Gone: the block was the rewriter's append for a transitive gem") is that the block and the DEPENDENCIES entry both go away. The documented "comes back as the exact pin" caveat covers a gem that had a declaration, not one the user never declared.
  • Actual: a new gem "rack", "3.2.1" line and a rack (= 3.2.1) DEPENDENCIES entry.

Matrix

OS Ruby Bundler Lock Result
Linux 3.3.6 4.0.17 CHECKSUMS (default) reproduces (rollback twice, remove once)
Linux 3.3.6 2.6.9 bundle lock --add-checksums reproduces
Linux 3.3.6 4.0.17 CHECKSUMS, Gemfile ends with a blank line pass (byte-identical restore)
Linux 3.3.6 2.6.9 no CHECKSUMS (mixed state) n/a: the lock isn't converged, and rollback can't see a Gemfile-only pin (documented)

The logic is plain text processing with no OS dependency, so macOS and Windows should behave the same. I didn't bisect: the upstream restore is new in v5 (#277), and main 2463257 is the first commit that has it.

Suspect code

  • crates/socket-patch-core/src/patch/redirect/mod.rs:5070: the transitive append is let sep = if gf.ends_with('\n') { "" } else { "\n" };, which leaves no blank line before the block.
  • crates/socket-patch-core/src/patch/redirect/upstream/gem.rs:480 (provably_appended) and :691: the restore requires a blank line before the block to choose Decl::Transitive. The unit test provably_transitive_needs_a_blank_line_before_the_block builds its "appended" fixture as gem "puma"\n\n{block}, a shape the rewriter never produces on an LF-terminated Gemfile.

One possible fix: have the rewriter's append write a blank separator, so its output is provably distinguishable from an in-place rewrite (which swallows the preceding blank lines). Hosted Gemfiles written by earlier runs would still need a fallback.

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

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.