`rollback -g` and `remove <purl> -g` also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 55/100
Piste de recherche
Run the provided vlt reproduction or probe workflow first, then inspect rollback.rs around lines 865, 959, and 1506-1530 and remove.rs around line 728. Trace the global and cwd paths, including the vendored ownership check. Done means global rollback, remove, and agent scan affect only the global installation and leave the current project's lockfile, vendor directory, and installed dependencies unchanged.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
[agent] Found by the scheduled vlt bug-hunt routine (ledger #307).
Summary
--global / -g is documented as "Operate on globally-installed packages". If socket-patch rollback -g or socket-patch remove <purl> -g runs from inside a project that uses hosted or vendored mode, it rolls back the global copy as expected. It also runs v5's full-state rollback legs against the cwd project:
- the project's hosted pins in
vlt-lock.jsonare restored to the registry, and - its vendored wiring is reverted: the lock is unwired and
.socket/vendor/is deleted.
On vlt this goes further: the run deletes the project's installed node_modules/left-pad (redirect_vlt_reinstall_required / vendor_vlt_reinstall_required). The project is left with a missing dependency until someone runs vlt install. The run exits 0 with status: success.
The same happens with an empty global prefix: there's nothing global to roll back, and the project still gets unwound.
The reverse direction has the same root cause. In a vendored project, scan -g --mode agent skips the global copy with vendored_ownership_retained, because the cwd project's vendor ledger "owns" the purl. It exits 0, and the global install stays unpatched.
Impact
- A user who runs
socket-patch rollback -gto undo a global patch silently loses the security patches of whatever repo they happen to be in. In CI, that's the checkout. The lockfile change looks like an ordinary diff and can get committed, which un-patches every latervlt ci/npm ci. - On vlt the working tree breaks right away:
require('left-pad')throwsMODULE_NOT_FOUND. - This isn't vlt-specific. An npm project (
package-lock.json, hosted or vendored) is unwound the same way. vlt just adds the deleted install.
Repro (vlt 1.3.3, any OS)
The patch API and registry are a local mock: patch aaaaaaaa-… for pkg:npm/[email protected], with registry on :18555 and patch server on :18556. The mock is in the probe workflow linked below.
export SOCKET_NPM_REGISTRY=http://127.0.0.1:18555 SOCKET_API_URL=http://127.0.0.1:18556 \
SOCKET_PATCH_SERVER_URL=http://127.0.0.1:18556 SOCKET_ORG_SLUG=test-org SOCKET_API_TOKEN=fake
export NPM_CONFIG_PREFIX=$PWD/gprefix; mkdir -p gprefix/lib/node_modules # empty global
mkdir proj && cd proj
echo '{"name":"app","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
echo '{"config":{"registries":{"npm":"http://127.0.0.1:18555/"}}}' > vlt.json
vlt install
socket-patch scan --yes # hosted (v5 default); or: scan --mode vendored --yes
rm -rf node_modules && vlt ci
node -e "console.log(require('left-pad'))" # patched
cp vlt-lock.json wired.lock
socket-patch rollback -g --yes --json; echo rc=$? # rc=0, status success
cmp wired.lock vlt-lock.json # differ: hosted URL / file:.socket/vendor edge gone
ls .socket/vendor # (vendored case) gone
node -e "require('left-pad')" # MODULE_NOT_FOUND
# same with: socket-patch remove pkg:npm/[email protected] -g --yes --json
Reverse direction: in a vendored project with left-pad also installed globally, socket-patch scan -g --mode agent --yes --json exits 0 with warning vendored_ownership_retained, and $NPM_CONFIG_PREFIX/lib/node_modules/left-pad stays unpatched.
Expected vs actual
- Expected:
--globalmeans "Operate on globally-installed packages" (CLI_CONTRACT.md, Global arguments). Global targeting has "no project lockfile to rewire" (Mode resolution:--mode hostedwith--globalis a usage error for exactly that reason). Lockfile discovery explicitly excludes global scans ("Global scans (--global) get no supplement"). So the hosted and vendored legs of rollback/remove should not run under-g, and a cwd vendor ledger shouldn't decide ownership of a global copy. A-grollback should touch only the global tree (plus the manifest records for it). - Actual: the full-state rollback's vendored leg (
run_vendored_leg) and hosted leg (run_hosted_leg) run unconditionally against--cwd, whatever--global/--global-prefixsays.remove -gshares the hosted leg andrevert_vendored_matches.
OS × vlt matrix (main 2463257)
Every cell is rollback -g and remove -g for both a hosted and a vendored vlt project. The project lock is rewritten, .socket/vendor is deleted, node_modules/left-pad goes missing, and the exit is 0.
| OS | vlt 1.0.10 | vlt 1.2.0 | vlt 1.3.3 |
|---|---|---|---|
| Linux (sandbox + ubuntu-latest) | repro | repro | repro |
| macOS (macos-latest) | repro | repro | repro |
| Windows (windows-latest) | repro | repro | repro |
npm 10 projects (package-lock.json, hosted and vendored) on Linux also reproduce: the lock is rewritten, exit 0.
First bad commit
Bisected on an npm project (vlt support didn't exist yet), local, 2/2 runs each:
| Build | npm hosted rollback -g |
npm vendored rollback -g |
|---|---|---|
| release 4.0.0 | project untouched (rc 1) | project untouched (rc 0) |
3a2b06d (parent of #231) |
project untouched | project untouched |
d5e1815 (#231, "full-state rollback default") |
lock rewritten, rc 0 | lock rewritten, rc 0 |
f6b7fb9, 2463257 (main) |
lock rewritten | lock rewritten |
So it's a v5 regression from #231, which added the vendored and hosted legs to the default rollback.
Suspect code
crates/socket-patch-cli/src/commands/rollback.rs:1506-1530: the vendored leg (run_vendored_leg,:865) and the hosted leg (run_hosted_leg,:959) run with nocommon.global/common.global_prefixcheck.crates/socket-patch-cli/src/commands/remove.rs:728(revert_vendored_matches) and its use ofrun_hosted_leg: same.- The vendor-ownership skip in the agent apply path, which consults the cwd ledger under
-g(vendored_ownership_retained).
Related
- #436 (yarn classic) covers
get -g --mode hosted|vendoredandscan -g --mode vendoredrewiring the project. That's a different command path (explicit mode on get/scan), but it's the same family:-gfalling through to cwd project state.
Probe run: https://github.com/SocketDev/socket-patch/actions/runs/36834317384 (3 OS × vlt 1.0.10 / 1.2.0 / 1.3.3; OBS bug.* lines). The Windows default-prefix -g failures in that run are #434. The readonly.* FAILs are a probe artifact (the runner user owns the files).
- Langage dominant
- Rust
- Étoiles
- 8
- Forks
- 0
- Merge moyen
- 1 j 31 min
- PR mergées (30 j)
- 151
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: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
-
agent:triaged bug bughunt pm:pipenv priority:p1
Difficulté 2/5 1-3 heures Accessibilité débutants 83/100
SocketDev/socket-patch#744 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
agent: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
-
agent:triaged bug bughunt pm:composer priority:p2
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
SocketDev/socket-patch#515 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
A report-only `scan -g` tells you to run `socket-patch scan --mode agent [PATHS]` without `-g`, so following the hint scans the cwd project instead of the global installPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverteagent:triaged bug bughunt pm:npm priority:p1
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
SocketDev/socket-patch#464 · 1 commentaire ·
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 72/100
pnpm/pnpm#16635 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
[Bug]: Bedrock request metadata forwarding does not work for /embeddingsPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouvertebug llm translation
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
pytest plugin: a crashed xdist worker aborts the whole session with INTERNALERRORPeut-être pris @hazelxue l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour
-
skillfs: one malformed chat-log line aborts the entire skill-usage analysis (skill_usage_from_chat_logs.py)Peut-être pris @zjncs l’a pris aujourd’hui. Ouvertecomponent:skillfs
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
agentic-os-org/ANOLISA#6116 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour