npm v2 lock: aliased packages stay on the registry in the legacy dependencies mirror (hosted silently, vendored with a warning), so npm 6 installs unpatched bytes while VEX attests not_affected
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
Línea de trabajo
Read crates/socket-patch-core/src/vendor/npm_lock.rs:950-972, the npm redirect code under crates/socket-patch-core/src/patch/redirect/, and manifest-less discovery under crates/socket-patch-core/src/vex/discover/. Run the supplied npm 6/npm 12 alias reproduction in hosted and vendored modes first. Done means the legacy alias behavior is safe or clearly reported in both modes, and lockfile-only VEX does not make a false not_affected attestation.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
[agent] Found by the scheduled npm bug-hunt routine (ledger #302).
Summary
Take a lockfileVersion 2 package-lock.json, the format npm 7 and 8 write, which also carries the legacy dependencies mirror that npm 6 reads. When it holds an npm alias ("lp": "npm:[email protected]"), hosted and vendored mode rewrite only the packages["node_modules/lp"] entry. The mirror node dependencies.lp ("version": "npm:[email protected]") keeps its registry resolved and integrity.
- Hosted (the v5 default) does this silently. Its only warning is
redirect_npm_allow_remote. - Vendored warns
vendor_legacy_alias_skipped("npm 6 clients reading the v2 legacy mirror still install the UNPATCHED registry bytes through it"). Seecrates/socket-patch-core/src/vendor/npm_lock.rs:950-972.
In both modes, manifest-less socket-patch vex then attests the package not_affected from the lockfile. Meanwhile npm ci with npm 6 on that same committed lock installs the unpatched registry tarball and exits 0.
Non-aliased entries don't have this problem: the mirror is rewritten, and npm 6 installs the patched bytes. That holds for both hosted and vendored, and for nested entries too.
A related symptom in the same area: with an npm 6 lockfileVersion 1 lock and the same alias, hosted scan writes nothing. It warns redirect_npm_entry_not_found: no package-lock.json entry for [email protected] and exits 0 success, even though the lock contains the alias entry "lp": {"version": "npm:[email protected]", ...}.
Impact
Docs list npm 6 as able to install a v2 lock (docs/testing/npm-compatibility.md, docs/ecosystems.md:56). A project that commits a v2 lock and has any npm 6 consumer (CI image, developer machine) gets the vulnerable code. Its VEX document still claims the vulnerability is not exploitable, which is the false attestation VEX must never make. Vendored at least warns at write time. Hosted gives no signal at all.
Repro
This uses a local mock of the patch API (batch / by-package / patches/package / patches/view / the tarball route), with --patch-server-url pointing at it. The patched tarball prepends /* SOCKET-PATCHED */ to index.js.
SPA="--api-url http://127.0.0.1:8765 --org o --api-token fake --patch-server-url http://127.0.0.1:8765"
mkdir repro && cd repro
echo '{"name":"t","version":"1.0.0","private":true,"dependencies":{"lp":"npm:[email protected]"}}' > package.json
npx -y [email protected] install # lockfileVersion 2
socket-patch scan $SPA --json # hosted: status success, redirected 1, warnings: [redirect_npm_allow_remote]
node -e 'const l=require("./package-lock.json");console.log(l.packages["node_modules/lp"].resolved, l.dependencies.lp.resolved)'
# http://127.0.0.1:8765/patch/npm/<token>/<uuid>/left-pad-1.3.0.tgz https://registry.npmjs.org/left-pad/-/left-pad-1.3.0.tgz
# fresh checkouts of the committed files (package.json, package-lock.json, .npmrc)
(cp -r ../repro ../c6 && cd ../c6 && rm -rf node_modules && npx -y [email protected] ci && head -c 21 node_modules/lp/index.js) # "/* This program is fr" (UNPATCHED)
(cp -r ../repro ../c12 && cd ../c12 && rm -rf node_modules && npx -y [email protected] ci && head -c 21 node_modules/lp/index.js) # "/* SOCKET-PATCHED */"
(cp -r ../repro ../lo && cd ../lo && rm -rf node_modules && socket-patch vex $SPA -O v.json) # 1 statement: not_affected
To see the vendored twin, run socket-patch scan --mode vendored $SPA instead of the hosted scan. It prints the vendor_legacy_alias_skipped warning. npm 6 ci again installs unpatched bytes, and lockfile-only vex is again not_affected.
Expected vs actual
- Expected: CLI_CONTRACT.md's lockfile table says for npm lock v2: "v2 legacy
dependenciesmirror … legacy mirror rewritten". So the alias mirror node should be rewritten like the non-alias ones. Failing that, the run should at least fail loudly in hosted mode (the vendored warning parity). VEX should also withhold the attestation while a lock that some supported npm reads still resolves the package from the registry. That's the same principle aspatched_ref_unattributablefor the dual-lock shrinkwrap/package-lock case. - Actual: hosted rewrites only the
packageshalf, silently. Vendored does the same with a warning. VEX attestsnot_affectedin both modes, while npm 6 installs the unpatched bytes.
Matrix (Linux, Node 22.22)
| Lock writer | Mode | npm 6.14.18 ci |
npm 12.1.0 ci |
lockfile-only vex |
|---|---|---|---|---|
npm 8.19.4 (v2), alias lp + scoped alias @x/lp |
hosted | unpatched | patched | not_affected |
| npm 8.19.4 (v2), alias | vendored | unpatched (warned at write) | n/a | not_affected |
npm 8.19.4 (v2), plain is-number + nested copy (control) |
hosted | patched | patched | not_affected (correct) |
| npm 6.14.18 (v1), alias | hosted | nothing written, redirect_npm_entry_not_found, exit 0 |
— | no refs |
First bad version
This isn't a v5 regression. Release 4.0.0 (scan --mode hosted) leaves the same alias mirror nodes on the registry. Main 2463257 behaves the same way.
Suspect code
- Vendored:
crates/socket-patch-core/src/vendor/npm_lock.rs:950(rewrite_legacy_tree, thevendor_legacy_alias_skippedbranch). - Hosted: the npm
package-lock.jsonredirect undercrates/socket-patch-core/src/patch/redirect/has no counterpart warning and no alias-mirror rewrite. - VEX: manifest-less npm lock discovery (
crates/socket-patch-core/src/vex/discover/) attests from thepackageshalf without checking the legacy mirror.
- Lenguaje dominante
- Rust
- Estrellas
- 8
- Forks
- 0
- Merge medio
- 19 h 21 min
- PR fusionados (30 d)
- 421
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de SocketDev/socket-patch
-
agent:triaged bug bughunt pm:npm priority:p3
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
SocketDev/socket-patch#1072 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Hosted gem `rollback` / `remove` strips the `DEPENDENCIES` `!` of a gem the user declared inside a `source "https://rubygems.org" do` block, so every frozen install fails after the unwindPosiblemente ocupada @mikolalysenko la tomó hoy. Abiertoagent:triaged bug bughunt pm:bundler priority:p1
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
SocketDev/socket-patch#1056 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
agent:triaged bug bughunt pm:bundler priority:p1
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
SocketDev/socket-patch#896 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
SocketDev/socket-patch#783 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
agent:triaged bug bughunt pm:cargo priority:p2
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
SocketDev/socket-patch#651 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de SocketDev/socket-patch
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
rescript-lang/rescript#8765 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
farion1231/cc-switch#8072 ·
Los mantenedores suelen responder en 1 día
-
Python 3.15 supportPosiblemente ocupada @amnesiaof la tomó hoy. AbiertoL: python L: python:uv
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
dependabot/dependabot-core#16524 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
[Bug]: Migration link in chromadb/config.py error message returns 404Posiblemente ocupada @Imad2702 la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
chroma-core/chroma#7879 ·
Los mantenedores suelen responder en 1 día