Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#1,821 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@mikolalysenko ya está trabajando en esto.

Desde el 29/10/2026.

  • #1822 de @mikolalysenko — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
ruby, rust
Área
backend, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).
Lenguaje dominante
Rust
Estrellas
8
Forks
2
Merge medio
19 h 12 min
PR fusionados (30 d)
709

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SocketDev/socket-patch

Todos los issues de SocketDev/socket-patch

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.