Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Vendored gem mode writes the rewired `gem` line of a CRLF Gemfile with an LF ending, leaving the Gemfile with mixed line endings

已關閉
  • 哪裡不對？
#1,821 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

@mikolalysenko 已經在處理了。

開始於 2026年10月29日。

  • #1822 來自 @mikolalysenko —— 未關閉

評估

難度
3/5
預估耗時
1-2 天
新手友好度
25/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
停滯
技術堆疊
ruby, rust
領域
backend, cli

研究方向

Start with crates/socket-patch-core/src/vendor/gem.rs, especially plan_gemfile_edit, apply_gemfile_plan, and the Append arm; the report also points to restore_gemfile_line. Reproduce with the CRLF Gemfile case in crates/socket-patch-cli/tests/e2e_vendor_gem_build.rs and verify the rewritten line retains CRLF. A pull request is already open for this issue.

由索引模型根據 Issue 內容生成。

描述

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

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

Summary

When vendored mode rewires a gem declaration in a CRLF Gemfile, the new gem "x", "<ver>", path: "…" line is written with a bare \n. Every other line keeps \r\n. So after socket-patch vendor the Gemfile has mixed line endings:

source "https://rubygems.org"\r\n
\r\n
gem "rack", "3.2.7", path: ".socket/vendor/gem/<uuid>/rack-3.2.7"\n     <- was "...\"~> 3.1\"\r\n"

vendor --revert, rollback and remove restore the recorded original line (with its \r), so the round trip is byte-exact. The vendored state in between is the problem. Bundler parses the file fine, so installs and bundle exec aren't affected.

This is separate from #1808, which is about the CRLF Gemfile.lock (the lock surgery). Its fix PR #1811 only touches the lock path and doesn't change the Gemfile line.

Impact

  • A project that commits its Gemfile as CRLF (.gitattributes -text or eol=crlf with a non-normalizing checkout, or Windows editors with autocrlf=false) commits a mixed-ending Gemfile after vendoring. The diff shows an EOL change on top of the real edit, and RuboCop Layout/EndOfLine (crlf / native on Windows) flags the line.
  • This is inconsistent with hosted mode, which keeps a CRLF Gemfile CRLF (gemfile_rerun_on_crlf_checkout_never_nests), and with the CRLF-preservation fixes the vendored backends got for other manifests (#662 pnpm package.json, #1567 requirements.txt).

Severity is low: the file still works. It's a correctness and hygiene defect in a user-owned manifest.

Repro

This is a scratch addition to gem_vendor_fresh_checkout_bundle_install_and_revert in crates/socket-patch-cli/tests/e2e_vendor_gem_build.rs, with a real bundle install from rubygems.org and the patch staged offline with stage_patch_with_vuln:

Gemfile (CRLF):  source "https://rubygems.org"\r\n\r\ngem "rack", "~> 3.1"\r\n
bundle config set --local path vendor/bundle && bundle install      # Gemfile.lock stays LF
# stage a lib/rack.rb patch for pkg:gem/[email protected]
socket-patch vendor --json --offline        # exit 0, applied 1
ruby -e 'p File.binread("Gemfile")'
# => "source \"https://rubygems.org\"\r\n\r\ngem \"rack\", \"3.2.7\", path: \".socket/vendor/gem/<uuid>/rack-3.2.7\"\n"
socket-patch vendor --revert --json         # (or rollback / remove <purl>) -> Gemfile byte-exact CRLF again

Expected vs actual

  • Expected: a rewritten line keeps the line ending of the line it replaces (or utils::line_endings::terminator of the file), as hosted mode does for the same Gemfile. docs/ecosystems.md lists the vendored Gemfile + Gemfile.lock pair edit as supported, with no line-ending caveat, and #815 / #1108 set one terminator rule for lines a writer inserts.
  • Actual: the rewired line ends in \n inside a CRLF file.

Matrix (Linux, Ruby 3.3.6; the edit is pure text handling, so it doesn't depend on the OS)

Case Bundler 2.6.9 Bundler 4.0.23
vendor on CRLF Gemfile + LF lock: vendored Gemfile has mixed endings fail (×3) fail (×3)
… then vendor --revert / rollback / remove: Gemfile and lock byte-exact pass pass
LF Gemfile (control) pass pass

macOS / Windows probes are unavailable (push-triggered probe runs don't start, see #316). Tested on main ecd4924 (v5.0.1).

Suspect code

  • crates/socket-patch-core/src/vendor/gem.rs:1346-1360 (plan_gemfile_edit): new_line is built from scratch (format!("gem {q}{name}{q}, …")) while original_line is lines[idx] from text.split('\n'), so it still carries the \r. The new line drops it unless a trailing comment happens to carry it. apply_gemfile_plan (gem.rs:1610-1633) then joins with \n.
  • The RewireOurs arm keeps the \r (replacen on the original), and the Append arm (transitive gem, GemfilePlan::Append { block }) appends an LF-only block. I didn't run the Append arm here.
  • A related shape I saw (not filed separately): after a vendored LF pair is re-checked-out as CRLF, restore_gemfile_line (gem.rs:2403) writes back the recorded LF original into the CRLF file. With #1811 applied, vendor --revert on such a checkout then leaves the Gemfile mixed as well (…\r\n\r\ngem "rack", "~> 3.1"\n).
主要語言
Rust
星號
8
分支
2
平均合併
19 小時 12 分鐘
30 天內合併 PR
709

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

SocketDev/socket-patch 的其他 Issue

查看 SocketDev/socket-patch 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。