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

Start with crates/socket-patch-core/src/crawlers/ruby_crawler.rs:236-263 and inspect how gem_env_gems_dirs orders gemdir and gempath. Then read crates/socket-patch-cli/src/commands/vex.rs:556 and the gem rule in vex_consumed.rs. Reproduce the user-install or GEM_PATH case, and consider the issue complete when manifest-basis VEX results reflect the copy RubyGems and Bundler load, including the reverse-direction case.

[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 [email protected] 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/[email protected] --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". #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)

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