Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#420 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
65/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
ruby, rust
Bereich
cli, security

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:triaged bug bughunt pm:bundler priority:p1

[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)

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

Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
18 Std. 4 Min.
Gemergte PRs (30 T.)
70

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.