Hosted gem `rollback` / `remove` strip the DEPENDENCIES `!` when the user's `source … do` block opens after a `;` on the same line, so frozen installs fail on Bundler 4.0.19+
Les mainteneurs répondent en général sous 1 jour
Une pull request liée a déjà été fusionnée.
- #1537 par @mikolalysenko — fusionnée
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
Piste de recherche
Start in crates/socket-patch-core/src/patch/redirect/upstream/gem.rs around lines 627-637 (block_stack), where source_pending is only set from a leading source on a line. Reproduce with the e2e test gem_hosted_unwind_keeps_a_source_block_bang in crates/socket-patch-cli/tests/e2e_redirect_gem_build.rs using the ; fixture, and check in_source_block returns true for the ; shape. Done when the restored lock keeps the ! and the frozen install exits 0 on Bundler 4.0.19+.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
[agent] Found by the scheduled Bundler (RubyGems) bug-hunt routine (ledger #316).
Summary
This is a neighbour of #1056 / #1476 / #1509, still open on main after #1520. The hosted unwind (rollback / remove) decides whether a restored gem gets its ! source pin in Gemfile.lock DEPENDENCIES by asking in_source_block. The block scanner only recognises a source statement at the start of a line. A source "…" do that follows another statement and a ; on the same line is read as a plain do block:
source "https://rubygems.org"
zz = 1; source "https://rubygems.org" do
gem "vuln-gem", "1.0.0"
end
Bundler evaluates this as a source block and locks vuln-gem (= 1.0.0)!. After scan --mode hosted → bundle install → rollback (or remove <purl>), socket-patch restores the Gemfile byte for byte but writes vuln-gem (= 1.0.0) without the !. On Bundler 4.0.19+ the next frozen install (BUNDLE_FROZEN=true / deployment / CI) fails with exit 16 ("Your lockfile needs to be updated, but it can't be because frozen mode is set"). 4.0.18 and older only warn.
Impact
After an unwind the project's lock no longer matches what Bundler derives from the Gemfile, so every frozen CI or deploy install fails until someone runs an unfrozen bundle install by hand. The ; spelling isn't common, but it's legal Ruby, and things like git_source(:gh) { … }; source "…" do show up in generated Gemfiles. Nothing gets silently unpatched: this is a broken-lock bug, not a security bypass.
Repro
This uses the repo's own harness. In crates/socket-patch-cli/tests/e2e_redirect_gem_build.rs, change the Driver::ScanVexSourceBlockMultiLineOpener fixture body to the ; shape and run the existing capstone:
Driver::ScanVexSourceBlockMultiLineOpener => format!(
- "source \"{up}/upstream\"\n\nsource(\n \"{up}/upstream\"\n) do\n \
+ "source \"{up}/upstream\"\n\nzz = 1; source \"{up}/upstream\" do\n \
gem \"{DEP}\", \"{DEP_VERSION}\"\nend\n",
gem install bundler -v 4.0.23
BUNDLER_VERSION=4.0.23 SOCKET_PATCH_BUNDLER_E2E_VERSION=4.0.23 SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1 \
cargo test --release -p socket-patch-cli --test e2e_redirect_gem_build \
gem_hosted_unwind_keeps_a_source_block_bang -- --include-ignored --nocapture
Output:
assertion `left == right` failed: rollback: the lock comes back byte for byte, `!` included
left: "…DEPENDENCIES\n vuln-gem (= 1.0.0)\n…"
right: "…DEPENDENCIES\n vuln-gem (= 1.0.0)!\n…"
With the lock assertion relaxed, the fresh-checkout BUNDLE_FROZEN=true bundle install exits 16 for both rollback and remove. In the same run, the plain, assignment (#1476) and brace (#1509) fixtures restore the ! and their frozen installs exit 0.
A unit probe of in_source_block agrees: in_source_block("x = 1; source \"https://x\" do\n gem \"rails\"\nend\n", at gem) returns false. The other 52 shapes I probed (\-continued do, a brace block nested in group, heredocs, %w(end), for … do end, CRLF, …) all return the expected answer.
Expected vs actual
- Expected: CLI_CONTRACT.md / docs/ecosystems.md ("Hosted unwind coverage") say
rollback/removerestore the upstream lock, and the #1056 fix restores a source-block gem's!pin "whichever URL the block names". The restored pair should pass a frozen install, as it does for the line-leadingsource … doform. - Actual: the
!is dropped, and frozen installs fail on Bundler 4.0.19+.
Matrix
| OS | Ruby | Bundler | zz = 1; source … do → rollback |
→ remove |
Line-leading source … do (control) |
|---|---|---|---|---|---|
| Linux | 3.3.6 | 4.0.23 | fail (! dropped, frozen exit 16; ×2) |
fail (exit 16) | pass |
| Linux | 3.3.6 | ≤ 4.0.18 | ! dropped; Bundler only warns (exit 0), as in #1509 |
same | pass |
| macOS / Windows | — | — | not run (OS-independent text scan) |
Suspect code
crates/socket-patch-core/src/patch/redirect/upstream/gem.rs:627-637 (block_stack): source_pending is set only from masked.strip_prefix("source") at the start of a line. In the masked.split(';') loop, every statement after the first gets source_pending = false and is never checked for a leading source. Deciding source_pending per ;-statement (at depth 0) should fix it.
Tested on main a8da202. I didn't run a probe branch, because the scan is pure text.
- Langage dominant
- Rust
- Étoiles
- 8
- Forks
- 1
- Merge moyen
- 16 h 35 min
- PR mergées (30 j)
- 574
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de SocketDev/socket-patch
-
agent:triaged bug bughunt pm:bundler priority:p1
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
SocketDev/socket-patch#1573 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
agent:triaged bug bughunt pm:poetry priority:p1
Difficulté 2/5 1-3 heures Accessibilité débutants 80/100
SocketDev/socket-patch#1547 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
agent:triaged bug bughunt pm:npm priority:p3 ux
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
SocketDev/socket-patch#1072 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
Difficulté 2/5 1-3 heures Accessibilité débutants 73/100
SocketDev/socket-patch#783 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package]Peut-être pris @mikolalysenko l’a pris il y a 4 jours. Ouverteagent:triaged bug bughunt pm:cargo priority:p2
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
SocketDev/socket-patch#651 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de SocketDev/socket-patch
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
adorsys/status-list-server#698 ·
Les mainteneurs répondent en général sous 2 jours
-
Expose the dot grid colourOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
nannou-org/egui_graph#92 ·
Les mainteneurs répondent en général sous 1 jour
-
documentation good first issue
Difficulté 2/5 Une demi-journée Accessibilité débutants 72/100
sujithputta02/Esapay#13 ·
-
Deduplicate normalized_f64_bits (hash_table.rs and bloom_filter.rs)Peut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
tursodatabase/turso#10002 ·
Les mainteneurs répondent en général sous 1 jour
-
needs triage
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
topgrade-rs/topgrade#2419 ·
Les mainteneurs répondent en général sous 1 jour