Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#1,125 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
75/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
ruby, rust
Domaine
cli

Piste de recherche

Examinez crates/socket-patch-core/src/patch/redirect/mod.rs à proximité des lignes 6098–6445. La garde à la ligne 6205 est contournée lorsque locked vaut None; ajoutez une vérification pour que les projets sans verrou ignorent le pinning ou l'ajout de gems. Validez avec les fixtures de e2e_redirect_gem_build.rs qu'un scan uniquement sur le Gemfile laisse le manifest inchangé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

agent:triaged bug bughunt pm:bundler priority:p1

[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

OS Ruby Bundler Shape Result
Linux 3.3.6 2.5.22 lockless ~> 2.0 declaration fails (downgrade to 1.0.0)
Linux 3.3.6 2.5.22 lockless, gem not declared fails (gem appended and installed)
Linux 3.3.6 4.0.18 both shapes fails (same, CHECKSUMS lock written by the install)
Linux 3.3.6 4.0.18 same shapes with a lock (the #1055 control) pass (redirect_gem_version_not_locked, repo e2e suite)
macOS / Windows — — — untested; the logic is OS-independent

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.

Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
1 j 1 h
PR mergées (30 j)
257

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.