Gem `vex` checks the `gem env gemdir` copy instead of the `Gem.path` copy Ruby loads, so it attests `not_affected` while an unpatched `--user-install` / `GEM_PATH` copy runs

[mikolalysenko]

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

Summary

When one gem@version is installed in more than one gem home, vex (agent / manifest basis, with or without -g) verifies only the first copy the ruby crawler lists. That's always the gem env gemdir home (the Ruby install's gem dir, or GEM_HOME). RubyGems and Bundler load the copy from the first Gem.path entry instead. Gem.path lists the user gem dir (gem install --user-install) and every GEM_PATH entry before GEM_HOME. So when the loaded copy is unpatched and the gemdir copy is patched, vex writes not_affected for code that is actually vulnerable at runtime. In the reverse case (loaded copy patched, gemdir copy not), it refuses to attest a patched install.

apply / get / rollback are fine. They fan out to every copy (#222), so right after get -g both copies are patched. The bug appears as soon as the loaded copy is reinstalled: gem install --user-install <gem> again, gem pristine --user-install, or a reinstall into a GEM_PATH home.

Impact

A false OpenVEX not_affected statement (inline_mitigations_already_exist) for a package whose loaded code is unpatched. This is the "VEX attestation for a patch that isn't actually applied" class. It hits both vex -g and plain vex in a Bundler project that uses system gems (no BUNDLE_PATH), because bundle exec also loads the user-dir copy.

Repro (Linux; a local mock of the patch API serves one patch for colorize@0.8.1 that appends # SOCKET-PATCHED to lib/colorize.rb)

gem install colorize -v 0.8.1 --no-document                  # system gem home (gem env gemdir)
gem install --user-install colorize -v 0.8.1 --no-document   # ~/.local/share/gem/ruby/X (first in Gem.path)
SP="socket-patch --api-url http://127.0.0.1:18999 --api-token fake --org org"
$SP get -g 11111111-2222-4333-8444-555555555555 --yes        # patches BOTH copies (2 "Patched packages" lines)
gem install --user-install colorize -v 0.8.1 --no-document   # user reinstalls -> the copy Ruby loads is pristine again
ruby -e 'require "colorize"; f=$LOADED_FEATURES.grep(/colorize.rb/)[0]; puts f, File.read(f)[/SOCKET-PATCHED/] ? "PATCHED" : "UNPATCHED"'
#   /root/.local/share/gem/ruby/3.3.0/gems/colorize-0.8.1/lib/colorize.rb
#   UNPATCHED
$SP vex -g --product pkg:gem/myapp@1.0.0 --output vex.json
#   Using ruby gem paths at: /opt/rbenv/versions/3.3.6/lib/ruby/gems/3.3.0/gems
#   Wrote OpenVEX document with 1 statement   (exit 0)
grep -o '"status": "[a-z_]*"' vex.json
#   "status": "not_affected"

The same thing happens with:

• an explicit GEM_HOME=/tmp/gh GEM_PATH=/tmp/gp (Ruby loads /tmp/gp/..., vex -g checks /tmp/gh/...);
• a plain Bundler project (gem "colorize", "0.8.1", no BUNDLE_PATH) with get <uuid> --mode agent and then vex. bundle exec loads the user-dir copy, and vex still says not_affected.

Reverse direction: when only the loaded user copy is patched, vex -g says omitting … (not_applied) and exits 1.

Expected vs actual

• Expected: vex only attests what's applied to the code that runs. crates/socket-patch-cli/src/commands/vex_consumed.rs already states the gem rule for hosted-basis purls: "bundler loads whichever Gem.path home it hits first: ALL must verify". fix(gem): crawl bundle-path roots in bundler precedence order, patch every coexisting copy, contain config-sourced roots #222 also says the single-representative consumers pick "the copy bundler actually loads".
• Actual: for manifest-basis purls, vex hashes only the crawler's first copy, and for gem homes that's always the gemdir copy, which isn't the one Gem.path resolves first.

OS × version (probe run below, plus local Linux)

OS	Ruby / RubyGems / Bundler	Gem.path[0] (loaded)	vex -g after user-copy reinstall
Linux (sandbox)	3.3.6 / 3.5.22 / 4.0.17	~/.local/share/gem/ruby/3.3.0	not_affected (also via GEM_PATH and plain vex)
ubuntu-latest	2.7.8 / 3.1.6 / 2.4.22	~/.gem/ruby/2.7.0	not_affected
ubuntu-latest	3.3.10 / 3.5.22 / 2.5.22	~/.local/share/gem/ruby/3.3.0	not_affected
ubuntu-latest	3.4.9 / 3.6.9 / 2.6.9	~/.local/share/gem/ruby/3.4.0	not_affected
macos-latest (arm64)	2.7.8 / 3.1.6 / 2.4.22	~/.gem/ruby/2.7.0	not_affected
macos-latest (arm64)	3.3.10 / 3.5.22 / 2.5.22	~/.local/share/gem/ruby/3.3.0	not_affected
macos-latest (arm64)	3.4.9 / 3.6.9 / 2.6.9	~/.local/share/gem/ruby/3.4.0	not_affected
windows-latest	2.7 / 3.3 / 3.4	user gem dir	not reached: global discovery itself is broken on Windows (#421)

First bad version

This isn't a v5 regression. gem_env_gems_dirs already put gemdir first in v4.0.0 and v3.3.0 (checked in the source only).

Suspect code

• crates/socket-patch-core/src/crawlers/ruby_crawler.rs:236-263 (gem_env_gems_dirs) pushes gem env gemdir first and then appends gem env gempath (which is already in Gem.path order and starts with the user dir / GEM_PATH). Using gempath order alone (it always contains gemdir) would match RubyGems.
• crates/socket-patch-cli/src/commands/vex.rs:556 (collapse_to_first) verifies manifest-basis gem purls against one copy only. The hosted path in vex_consumed.rs already requires every gem copy to verify.

Probe run (macOS/Windows/Linux × Ruby 2.7/3.3/3.4): https://github.com/SocketDev/socket-patch/actions/runs/36816092864

[mikolalysenko]

[agent] Triaged: priority:p1 (RubyGems/Bundler). Confirmed on main 2463257: gem_env_gems_dirs (crates/socket-patch-core/src/crawlers/ruby_crawler.rs) pushes gem env gemdir before the gempath entries, so the first copy is never the one Gem.path loads. No duplicate and no open fix PR. Related to #421 (same discovery function), but that one is a separate defect (Windows gem.cmd spawn), so they aren't clustered.

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-triaged on main 045d7ec: this is fixed by #517 (3757e27, "Check every installed copy before vex attests").

I ran the issue's repro twice on Linux (Ruby 3.3.6) against a local mock patch API:

1. A system gem home plus a --user-install copy. get -g patches both copies, then gem install --user-install colorize -v 0.8.1 puts back the pristine copy that Ruby loads (ruby -e 'require "colorize"…' prints UNPATCHED).
2. GEM_HOME=…/gh GEM_PATH=…/gp:…/gh, with the …/gp copy reinstalled after get -g.

In both cases vex -g --product pkg:gem/myapp@1.0.0 now prints:

Warning: omitting pkg:gem/colorize@0.8.1 from VEX: the patched files still hold the original content (not_applied)
Error: No applied patches with vulnerability metadata to attest.

It exits 1 and writes no not_affected statement. Closing as completed.

---

Generated by Claude Code