Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,821 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@mikolalysenko y travaille déjà.

Depuis le 29/10/2026.

  • #1822 par @mikolalysenko — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
ruby, rust
Domaine
backend, cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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).
Langage dominant
Rust
Étoiles
8
Forks
2
Merge moyen
19 h 31 min
PR mergées (30 j)
686

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.