Bug hunt ledger: Bundler (RubyGems) #316

[agent] 2026-09-30: Bundler (RubyGems) bug-hunt run

This is the first run, so the ledger started empty and there were no pm:bundler issues to re-triage.

Tested: main f6b7fb9 (CLI reports 4.0.0; latest release 4.0.0). Ruby 3.3.6 with Bundler 4.0.9 and 2.4.22 (also installed: 2.5.22, 2.6.9). Linux only.

Setup: the sandbox can't reach the Socket patch API. I used a temporary, uncommitted copy of crates/socket-patch-cli/tests/e2e_redirect_gem_build.rs. It keeps its wiremock (upstream compact index, patch registry, patches API) alive and takes the fixture Gemfile from an env var. For vendored runs I added a small stub patches/view/<uuid> returning blobContent. Every cell ended with a real bundle install on a fresh checkout and a byte/require check of the installed gem.

Cells

• Hosted, multi-line gem "x", ↵ require: false: fail → Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340. The Gemfile no longer parses (bundler exit 4), while the scan reports exit 0 / redirected: 1 and the in-run VEX says not_affected. Failed on 4.0.9 with a CHECKSUMS lock, 4.0.9 without CHECKSUMS, and 2.4.22.
• Hosted, gem "x" if … modifier: fail → Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340. The condition is silently dropped (bundler 4.0.9).
• Hosted, decl inside group :development, :test do with a version constraint + require: false: pass. Patched bytes installed; the block is dedented, which is cosmetic.
• Hosted, stale-install guard (redirect_gem_stale_install) with BUNDLE_PATH in the local .bundle/config, as an env var only, or in the global ~/.bundle/config (absolute): pass.
• Hosted rollback: restored the Gemfile byte-exact (single-line decl): pass.
• Vendored (get --mode vendored --vendor-source build), twin gems.rb + Gemfile: fail → Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341. Only Gemfile/Gemfile.lock are wired. Bundler reads gems.rb and installs upstream bytes, yet vex attests not_affected (vendored). Failed on 4.0.9 unfrozen and 2.4.22 --frozen.
• Vendored, gems.rb only: no write, exit 1 (package_not_installed / vendor_fetch_unverifiable). This is the documented "cannot vendor yet", but the refusal reason is odd, so it's on the backlog.
• macOS / Windows: untested. Both defects are OS-independent text/file-selection logic, so I spent no probe branches this run.

Issues

• Filed Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340: Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340
• Filed Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341: Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341

False positives ruled out

• vendor_fetch_failed / no_local_source on the first vendored attempt came from my mock (no artifact route), not a product bug. Use --vendor-source build plus a view stub with blobContent.
• bundle install --deployment exit 15 on Bundler 4 is the removed flag, not socket-patch.

Next

1. Native/platform gems on a CHECKSUMS-less lock (Bundler 2.2–2.5): the redirect_gem_platform_unsupported guard only reads CHECKSUMS lines, so a name (ver-x86_64-linux) GEM spec without CHECKSUMS may be redirected to the ruby-platform gem. Needs platform .gem fixtures.
2. Why vendored on a gems.rb-only project reports package_not_installed while the same install is found when a Gemfile twin exists (crawler / lock-inventory spelling handling).
3. setup (bundler plugin) on Bundler 2.2 / 2.3 / 4.x, the 1.x refusal and setup --check, with gems.rb, with git/path sources, and setup --remove.
4. A macOS/Windows probe branch running the hosted CRLF Gemfile/lock cells and a Windows BUNDLE_PATH with a drive letter or spaces.
5. Hosted with git- or path-sourced siblings in the lock, BUNDLE_GEMFILE=Gemfile.next dual-boot layouts, and scan from a subdirectory of a bundler project.

[agent] 2026-09-30: Bundler (RubyGems) bug-hunt run

Tested: main f6b7fb9 (v4.0.0, the latest release). Ruby 3.3.6 on Linux, with Bundler 4.0.17, 2.5.22, 2.4.22, 2.3.27, 2.2.33 and 1.17.3 (the last only for the BUNDLED WITH refusal). Main hasn't moved since run 1, so re-triage of #340 / #341 was a no-op: nothing landed that could fix them.

Setup: a temporary, uncommitted copy of e2e_redirect_gem_build.rs kept its wiremock (upstream compact index, patch registry, patches API with a blobContent view) alive in hold-open mode, and I drove the real CLI and bundler by hand. Every cell ended with a real bundle install / bundle exec ruby -e 'require …'.

Cells

• Hosted, platform-resolved gem (vuln-gem (1.0.0-x86_64-linux)) on a CHECKSUMS-less lock (backlog 1), Bundler 4.0.17: pass (no bug). The redirect writes the Gemfile source block. The next unfrozen install drops the locked platform spec ("possibly been yanked… ignoring") and installs the patched ruby-platform gem: PATCHED loads. The platform switch is deliberate. With a CHECKSUMS lock, redirect_gem_platform_unsupported fails closed.
• Agent + setup plugin, Gemfile: setup → get → install → bundle pristine → fresh clone → setup --remove:
  • 2.5.22 / 4.0.17: all pass (the remove is byte-exact).
  • 2.2.33 / 2.3.27 / 2.4.22: fail → Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389. bundle pristine reverts the patch and no hook fires. The patch comes back at the next bundle install, and setup --check flags not applied on disk. The root cause is on Bundler's side: before 2.5, pristine uses GemInstaller#install_from_spec, which never calls Plugin.hook.
• Agent + setup plugin, gems.rb, 4.0.17: pass (install, pristine, fresh clone).
• setup 1.x refusal: pass. A lock with BUNDLED WITH 1.17.3 makes setup exit 1 with the floor message, setup --check exit 1 on a hand-wired 1.x project, and the refusal still fires on a CRLF lock. With no lock, the machine bundler (4.0.17) is probed, as intended.
• Vendored, gems.rb only (backlog 2): pass (documented refusal). With a plain ruby-platform install the error is the clear no Gemfile at …/Gemfile. Run 1's odd package_not_installed reason came from its platform/mock setup, not the product.
• BUNDLE_GEMFILE: "Gemfile.next" in .bundle/config (dual boot), hosted + in-run VEX, and setup, 4.0.17: fail → Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390. Both wire Gemfile. The scan reports success with no warnings and attests not_affected, setup --check exits 0, and bundler loads Gemfile.next and runs VULNERABLE code. The post-install vex correctly refuses (not_applied).
• macOS / Windows: untested. Both new defects are OS-independent (Bundler's own code path in Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389, manifest selection in Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390), so I spent no probe branches.

Issues

• Filed Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389: Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389
• Filed Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390: Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390
• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 and Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 are still open. main is unchanged, so there was nothing to re-check.

False positives ruled out

• setup --json reports "packageManager": "npm" on a Bundler-only project. CLI_CONTRACT documents this ("defaults to npm, only meaningful when npm files were found").
• Bundler 1.17.3 on Ruby 3.3 can't resolve against the mock compact index. That's a harness limit, so I tested the 1.x refusal through BUNDLED WITH.

Next

1. Vendored mode with BUNDLE_GEMFILE in .bundle/config: confirm it shares the Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 gap, and add one comment to Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390.
2. Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 on Bundler 2.2–2.6, and the BUNDLE_GEMFILE env-only form with setup in CI.
3. Git- and path-sourced gems: hosted and agent patch targets (bundler/gems/<name>-<sha>), and whether the plugin's patch_target_files misses them.
4. A macOS/Windows probe branch: a CRLF Gemfile/lock hosted cell, a Windows BUNDLE_PATH with a drive letter or spaces, and the plugin's Dir.glob on x64-mingw-ucrt platform gems.
5. Ruby 2.7 and 3.4 runtimes (Bundler 2.2 doesn't boot on 3.4; check that setup still probes correctly).