Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do 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

Aberta Para iniciantes
  • Algo errado?
#1,125 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
75/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
ruby, rust
Domínio
cli

Direção de pesquisa

Examine crates/socket-patch-core/src/patch/redirect/mod.rs perto das linhas 6098–6445. A guarda na linha 6205 é contornada quando locked é None; adicione uma verificação para que projetos sem bloqueio pulem o pinning ou a adição de gems. Valide com os fixtures de e2e_redirect_gem_build.rs que uma varredura apenas do Gemfile deixe o manifest inalterado.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Rust
Estrelas
8
Forks
0
Merge médio
22h 30min
PRs com merge (30d)
329

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Todas as issues de SocketDev/socket-patch

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.