Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Hosted gem scan ignores a Gemfile `lockfile "custom.lock"` DSL call (Bundler 4), so it pins the unused Gemfile.lock, leaves the real lock untouched, and every frozen install fails

Chiusa
  • Qualcosa non va?
#1,477 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@mikolalysenko ci sta già lavorando.

Dal 13/10/2026.

  • #1479 di @mikolalysenko — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
ruby, rust
Ambito
backend, devtools

Direzione di ricerca

Start with crates/socket-patch-core/src/formats/gem/manifest.rs, especially LoadedManifest::with_lockfile and LoadedManifest::pair, and trace how the hosted engine reads Gemfile lockfile settings. Check crates/socket-patch-core/src/vendor/gem.rs and the existing Bundler 4 custom lockfile tests for the related vendored path. Add coverage for a Gemfile lockfile DSL call; done means hosted scans either refuse it without writing files or pin the lock Bundler actually uses, and frozen install succeeds.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

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

Summary

Bundler 4 has four ways to name a custom lockfile: BUNDLE_LOCKFILE in the env, the app config or the global config, plus a lockfile "<path>" call in the Gemfile itself. #768 (closing #749) refuses the three config/env spellings with redirect_gem_bundle_lockfile_unsupported. Nothing reads the Gemfile DSL spelling. With a Gemfile that starts with lockfile "custom.lock", scan --mode hosted:

  • rewrites the Gemfile (adds the patch-registry source … do block),
  • pins the leftover Gemfile.lock, which Bundler no longer reads,
  • leaves custom.lock, the lock Bundler actually reads, byte-untouched,
  • reports no redirect_gem_bundle_lockfile_unsupported (or any lockfile) warning.

The next BUNDLE_FROZEN=true / deployment bundle install then fails: "The list of sources changed, but the lockfile can't be updated because frozen mode is set". The same project installs frozen without trouble before the scan.

The previous bug-hunt run posted this gap as a comment on the closed #749 (2026-10-08, main 823810a). It still reproduces on main 15c2c83, so this issue tracks it on its own.

Impact

CI and production installs (frozen or deployment) of a Bundler 4 project that uses the lockfile DSL break after a hosted scan. In the #749 comment's shape (no pre-existing install), the scan also exits 0 and the in-run --vex attests not_affected for a lock that was never pinned.

Repro

I used a scratch copy of crates/socket-patch-cli/tests/e2e_redirect_gem_build.rs, gem_hosted_bundler4_custom_lockfile_redirects_nothing. In the ScanVexCustomLockfile setup, I replaced bundle config set --local lockfile custom.lock with prepending lockfile "custom.lock"\n to the Gemfile. custom.lock is a copy of the pristine lock, and Gemfile.lock is left behind, exactly as in the existing test. I replaced the assertions with prints, then ran:

SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1 cargo test -p socket-patch-cli --test <scratch copy> -- \
  gem_hosted_bundler4_custom_lockfile_redirects_nothing --include-ignored --nocapture
  • Pristine project with the DSL line: BUNDLE_FROZEN=true bundle install exits 0.
  • scan --mode hosted --json --vex … produces summary.applied: 1. Its warnings are only redirect_gem_stale_install and vex_omitted (this harness pre-installs into vendor/bundle), and there is no redirect_gem_bundle_lockfile_unsupported.
  • Gemfile and Gemfile.lock are rewritten (Gemfile.lock now has the patch-registry GEM section, vuln-gem (= 1.0.0)! and the patched sha256). custom.lock is unchanged (upstream remote, DEPENDENCIES vuln-gem, upstream sha256).
  • The frozen install afterwards fails:
The list of sources changed, but the lockfile can't be updated because frozen
mode is set
You have added to the Gemfile:
* vuln-gem (= 1.0.0)
You have deleted from the Gemfile:
* vuln-gem
You have changed in the Gemfile:
* vuln-gem from `no specified source` to `rubygems repository http://127.0.0.1:…/patch-registry/gem/…/`

Expected vs actual

  • Expected: docs/ecosystems.md (RubyGems row) says "bundler 4's BUNDLE_LOCKFILE … naming any other lock is refused with redirect_gem_bundle_lockfile_unsupported", and #749's contract is that the scan refuses, writes nothing and still installs frozen. Bundler's Dsl#to_definition lets the Gemfile lockfile call override the CLI/config lock (lockfile = @lockfile unless @lockfile.nil?, bundler 4.0.18 lib/bundler/dsl.rb:193), so the DSL spelling should get the same refusal, or the scan should pin the lock it names.
  • Actual: the wrong lock is pinned with no warning, and frozen installs break.

Matrix (Linux, Ruby 3.3.6)

Bundler main Lockfile spelling Refused custom.lock pinned Frozen install after scan
4.0.22 15c2c83 Gemfile DSL lockfile "custom.lock" no (×2) no fails
4.0.18 15c2c83 Gemfile DSL no no fails
4.0.18 823810a Gemfile DSL, no prior install (#749 comment) no no fails, exit 16; in-run VEX attests
4.0.x 15c2c83 .bundle/config / env / global BUNDLE_LOCKFILE yes (existing test) n/a passes
< 4.0 — n/a (the DSL method doesn't exist) — — —

macOS and Windows weren't probed. The logic is OS-independent.

Suspect code

LoadedManifest::with_lockfile (crates/socket-patch-core/src/formats/gem/manifest.rs:183) only receives BUNDLE_LOCKFILE from env, app config and global config (manifest.rs:262 reads the config key). No gem reader parses a top-level lockfile call in the Gemfile / gems.rb, so the hosted engine falls through to the default Gemfile.lock pair (LoadedManifest::pair). The vendored path (crates/socket-patch-core/src/vendor/gem.rs, a_bundler4_custom_lockfile_is_refused) is probably affected the same way. I didn't verify it this run. lockfile false (Bundler writes no lock) is a related, untested shape.

Lingua principale
Rust
Stelle
8
Fork
1
Merge medio
16h 35m
PR unite (30g)
574

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SocketDev/socket-patch

Tutte le issue di SocketDev/socket-patch

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.