Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,821 3 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@mikolalysenko já está trabalhando nisso.

Desde 29/10/2026.

  • #1822 de @mikolalysenko — aberto

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
25/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
ruby, rust
Domínio
backend, cli

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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).
Linguagem predominante
Rust
Estrelas
8
Forks
2
Merge médio
19h 31min
PRs com merge (30d)
686

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Todas as issues de SocketDev/socket-patch

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.