Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy

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

Summary

Bundler's config loader drops a trailing # comment from a .bundle/config value. socket-patch's line scraper (bundle_config_setting* / parse_bundle_config_path → unquote_bundle_config_value) keeps it. Take BUNDLE_PATH: .gems # project-local gems. Bundler installs into and loads from .gems/ruby/<abi>/. The crawler resolves the root to a directory literally named .gems # project-local gems, which doesn't exist, and falls back to the gem env homes.

Agent apply therefore patches the system copy of the gem and reports success. vex then attests not_affected while bundle exec loads the unpatched project copy. Nothing warns.

Bundler 4.1 writes .bundle/config values unquoted (BUNDLE_PATH: .gems), so a hand-added trailing comment produces exactly this shape. Bundler 2.4 through 4.1 all honour the commented value (verified below).

Impact

Silent unpatching plus a false VEX attestation: the patched bytes land in a copy the app doesn't load.
The same reader backs the other settings, so the divergence probably reaches them too. I traced these in the code but didn't run them end to end:
- BUNDLE_CACHE_PATH: vendor/gems # … → the hosted stale-install guard (CLI_CONTRACT.md "Gem stale-install guard") would look in the wrong cache dir.
- BUNDLE_PATH__SYSTEM: true # … → isn't seen as true (the Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 shape).
- BUNDLE_GEMFILE: gems.rb # … → redirect_gem_bundle_gemfile_unsupported, which fails closed.
- The global config tier (Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577) goes through the same reader.

Repro (Linux, Ruby 3.3.6; no API needed)

mkdir app && cd app && mkdir .bundle
printf 'source "https://rubygems.org"\ngem "colorize", "0.8.1"\n' > Gemfile
printf -- '---\nBUNDLE_PATH: .gems # project-local gems\n' > .bundle/config
gem install colorize -v 0.8.1          # a system copy also exists (common on dev machines / images)
bundle install                          # installs into ./.gems/ruby/3.3.0
# Hand-written agent manifest: one patch to package/lib/colorize.rb (appends a marker line),
# .socket/manifest.json + .socket/blobs/<afterHash> (git-sha256 hashes).
socket-patch apply --offline            # exit 0, "applied"
socket-patch vex --product pkg:gem/app@1.0.0 --output vex.json   # exit 0, not_affected
grep -c SOCKET_PATCHED_MARKER .gems/ruby/3.3.0/gems/colorize-0.8.1/lib/colorize.rb   # 0  (loaded copy)
grep -c SOCKET_PATCHED_MARKER "$(gem env gemdir)/gems/colorize-0.8.1/lib/colorize.rb" # 1  (unused copy)
bundle exec ruby -e 'require "colorize"; puts $LOADED_FEATURES.grep(/colorize.rb$/)'   # → ./.gems/... (unpatched)

Bundler's own view: bundle config get path → ".gems", and Bundler::YAMLSerializer.load("---\nBUNDLE_PATH: .gems # c") → {"BUNDLE_PATH"=>".gems"} (strip_comment in bundler/yaml_serializer.rb, 2.5+; 2.4.22's loader gives the same result).

Expected vs actual

Expected: install-root discovery follows Bundler's settings (CLI_CONTRACT.md: the bundle path, cache path and gemfile are resolved "in Bundler::Settings priority", and .bundle/config is read like Bundler reads it). So apply patches .gems/ruby/3.3.0/gems/colorize-0.8.1, and vex attests only if that copy is patched.
Actual: the comment becomes part of the path. The project copy is never crawled, the gem env copy is patched instead, and vex exits 0 with not_affected.

OS × version

OS	Ruby	Bundler	`BUNDLE_PATH: .gems # c`	Control `BUNDLE_PATH: .gems`
Linux	3.3.6	4.1.0.beta1 (written by `bundle config set --local path .gems`, comment appended)	fail (loaded copy unpatched, VEX `not_affected`)	—
Linux	3.3.6	4.0.22	fail (×2)	pass
Linux	3.3.6	2.6.9	fail	pass
Linux	3.3.6	2.4.22	fail	pass
macOS / Windows	—	—	untested (the parsing is OS-independent)	—

The v4.0.0 release (npm @socketsecurity/socket-patch-linux-x64-gnu@4.0.0) behaves the same, so this isn't a regression. Tested on main 9c43dfc.

Suspect code

crates/socket-patch-core/src/crawlers/ruby_crawler.rs:1474 (parse_bundle_config_path), :1507 (bundle_config_setting_including_empty) and :1520 (unquote_bundle_config_value). The value is trimmed and unquoted, but a # … tail isn't stripped the way Bundler's YAMLSerializer#strip_comment does it (val.split("#", 2).first.strip when the value contains # and doesn't start with it).
Open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 / Fix gem crawl ignoring Bundler path.system (#915) #916 add more readers on the same helper, so they inherit this.

No probe runs: the logic is OS-independent string parsing.

[agent] Follow-up from the same run: the cache_path variant is now verified, not just traced.

Bundler: with BUNDLE_CACHE_PATH: vendor/gems # committed gem cache in .bundle/config, Bundler.app_cache resolves to <proj>/vendor/gems on both 4.0.22 and 2.4.22, and bundle cache writes the archives there.
socket-patch (main 9c43dfc): I added one case to gem_hosted_stale_archive_at_configured_cache_path_warns_and_is_not_attested (e2e_redirect_gem_stale_install.rs) with that config line and a stale vendor/gems/<gem>.gem. The run is a hosted scan --vex. It emits no redirect_gem_stale_install warning and finishes "status":"success", so the committed stale archive goes unflagged. It failed at the warning-count assertion on both runs (2/2). The existing quoted BUNDLE_CACHE_PATH: "vendor/gems" case passes. The edit was local only and has been reverted.

So the trailing-comment divergence affects at least two readers: the agent install root (BUNDLE_PATH) and the hosted stale-install guard (BUNDLE_CACHE_PATH).

Generated by Claude Code

bundler: 2026-10-06 run 25 ledger (#951, #952)

[agent] Triaged as priority:p1 (Bundler). Confirmed on main 9c43dfc: unquote_bundle_config_value (crates/socket-patch-core/src/crawlers/ruby_crawler.rs:1520) trims and unquotes the value but never strips a # … tail the way Bundler's YAMLSerializer#strip_comment does, so every .bundle/config reader on this helper (path, cache_path, path.system, gemfile, global tier) is affected. No duplicate and no open PR. Open PRs #684 and #916 add readers on the same helper, so a fix at the helper covers them too. This is a different cause from #952, which is about Bundler.root.

Generated by Claude Code

[agent] Claiming this issue (shared root cause: unquote_bundle_config_value doesn't apply Bundler's strip_comment to .bundle/config values). Branch: agent/fix-bundle-config-trailing-comment. Claim-ID: 20261006T172655Z-2a8716

Generated by Claude Code

[agent] Draft fix PR: #953

Generated by Claude Code

Drop trailing # comments from .bundle/config

Keep commented path.system from reviving a path

[agent] Re-check (Bundler bug-hunt, ledger #316): I verified PR #953 at head 52542db against the original agent repro (Linux, Ruby 3.3.6, Bundler 4.0.22, .bundle/config = BUNDLE_PATH: .gems # project-local gems, real bundle install / bundle exec).

Binary	Copy `bundle exec` loads (`.gems/ruby/3.3.0/…`)	`vex`
main `9c43dfc`	unpatched (system copy patched instead)	`not_affected` (false)
PR #953 `52542db`	patched	`not_affected` (now true)

The issue stays open until the PR merges.

Generated by Claude Code

Navigation Menu

Repository navigation

Gem `.bundle/config` reader keeps a trailing `# comment` in the value, so a commented `BUNDLE_PATH` is missed, agent `apply` patches the system copy and `vex` attests `not_affected` while Bundler loads the unpatched project copy #951

Summary

Impact

Repro (Linux, Ruby 3.3.6; no API needed)

Expected vs actual

OS × version

Suspect code

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951

Description

Summary

Impact

Repro (Linux, Ruby 3.3.6; no API needed)

Expected vs actual

OS × version

Suspect code

Activity

mikolalysenko commented on Oct 6, 2026

mikolalysenko commented on Oct 6, 2026

mikolalysenko commented on Oct 6, 2026

mikolalysenko commented on Oct 6, 2026

mikolalysenko commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Gem `.bundle/config` reader keeps a trailing `# comment` in the value, so a commented `BUNDLE_PATH` is missed, agent `apply` patches the system copy and `vex` attests `not_affected` while Bundler loads the unpatched project copy #951