Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: `gem "x", "~> 2.0"` becomes the older patched `"1.0.0"`, and a gem the project never declared is appended as a new dependency

检查 crates/socket-patch-core/src/patch/redirect/mod.rs 的 6098–6445 行附近。第 6205 行的守卫在 locked 为 None 时会被绕过；添加检查以使无锁项目跳过固定或追加 gems。使用 e2e_redirect_gem_build.rs 的 fixtures 验证仅扫描 Gemfile 时 manifest 保持不变。

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

Summary

#1060 (the fix for #1055) skips a crawled gem version that the project's lock doesn't resolve (redirect_gem_version_not_locked). The check only runs when a lock exists, though: let locked = files.get(lock_name).map(...) is None for a project with a Gemfile / gems.rb and no Gemfile.lock / gems.locked, and if let Some(specs) = &locked then skips the guard completely. Library repos usually don't commit their lock, so this is the normal state of a fresh clone before bundle install.

In that state, a hosted scan on a machine whose shared gem home holds another project's copy of a patched gem does what #1055 described, and adds one more failure:

1. The constraint is overwritten. gem "vuln-gem", "~> 2.0" is rewritten to source "<patch registry>" do gem "vuln-gem", "1.0.0" end. The next bundle install installs 1.0.0, where the untouched Gemfile installs 2.0.0.
2. An unrelated gem is added. A Gemfile that never mentions vuln-gem (gem "tiny-dep" only) gets a new source … do gem "vuln-gem", "1.0.0" end block appended through the "genuinely undeclared (a transitive dep)" branch. The next bundle install adds vuln-gem (= 1.0.0)! to the project's dependencies. Without the scan the project installs only tiny-dep.

Both runs exit 0 and report redirected: 1 / action: "pinned". The only warning is redirect_gem_stale_install about the shared-home copy, which doesn't say that the project's declared dependencies changed. rollback / remove can't undo it either: a Gemfile-only pin isn't a reference without a lock (CLI_CONTRACT.md "Lockless pins"), so the user has to edit the Gemfile by hand.

Impact

• The project's dependencies change silently: it downgrades below the user's constraint, or it picks up a gem it never used.
• With --vex, the scan exits 1 because of the stale warning, but plain scan --mode hosted / CI runs exit 0 and leave the rewritten Gemfile for the user to commit.

Repro (real Bundler; hermetic mock upstream + patch registry, the e2e_redirect_gem_build.rs fixtures)

# upstream mock serves tiny-dep 1.0.0 and vuln-gem 1.0.0 + 2.0.0; the patch registry serves patched vuln-gem 1.0.0
export GEM_HOME=$TMP/shared-home GEM_PATH=$TMP/shared-home:<system gem dir>
# project A (another project on the same machine) puts vuln-gem 1.0.0 into the shared home
(cd a && printf 'source "<upstream>"\ngem "vuln-gem", "1.0.0"\n' > Gemfile && bundle install)

# project B: fresh clone, Gemfile only, no lock
cd b && printf 'source "<upstream>"\n\ngem "vuln-gem", "~> 2.0"\n' > Gemfile
socket-patch scan --mode hosted --json --yes --api-url <mock> --org test-org --api-token fake
#   exit 0, redirect.patches = [{purl: pkg:gem/[email protected], action: pinned}]
cat Gemfile
#   source "<upstream>"
#   source "<patch registry>/" do
#     gem "vuln-gem", "1.0.0"
#   end
bundle install    # → Gemfile.lock: vuln-gem (1.0.0) / DEPENDENCIES vuln-gem (= 1.0.0)!
# control: the same Gemfile without the scan → "Installing vuln-gem 2.0.0"

# project C: Gemfile declares only `gem "tiny-dep"`, no lock
socket-patch scan --mode hosted …   # exit 0; appends `source "<patch registry>" do gem "vuln-gem", "1.0.0" end`
bundle install    # DEPENDENCIES gains `vuln-gem (= 1.0.0)!`; the control installs only tiny-dep

Expected vs actual

• Expected (CLI_CONTRACT.md, redirect_gem_version_not_locked): hosted mode "re-points the version the lock resolves; it never picks a version", and "the user's declared constraint and the locked version are never overwritten". With no lock there's nothing resolved to re-point. The scan should skip these gems with a warning (the way cargo refuses a lockless project with redirect_cargo_lockless_dependents), or at least never append a gem the manifest doesn't declare and never replace a declared requirement that the crawled version doesn't satisfy.
• Actual: the crawled shared-home version is pinned as an exact top-level requirement in both shapes, and the scan reports success.

Matrix

Main b96a785, which includes #1060. Both shapes were reproduced twice, on two Bundler versions. I didn't bisect: the lockless path is outside the #1060 change, so this predates it.

Suspect code

• crates/socket-patch-core/src/patch/redirect/mod.rs:6098: locked is None without a lock.
• crates/socket-patch-core/src/patch/redirect/mod.rs:6205: if let Some(specs) = &locked, so the #1055 guard is skipped when there's no lock.
• crates/socket-patch-core/src/patch/redirect/mod.rs:6387 (in-place rewrite to the exact version) and :6445 (the "genuinely undeclared (a transitive dep): append a block" branch, which without a lock can't tell a transitive dep from an unrelated shared-home gem).

No probe runs: found and confirmed on Linux only.