fix(arborist): apply registry-tarball allow-remote exemption in linked strategy#9495
Merged
owlstronaut merged 1 commit intoJun 5, 2026
Conversation
owlstronaut
approved these changes
Jun 5, 2026
Contributor
|
🎉 Backport to |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In continuation of our exploration of using
install-strategy=linkedin the Gutenberg monorepo, which powers the WordPress Block Editor.Under
install-strategy=linked, a fresh install fails withEALLOWREMOTEon ordinary registry dependencies whose lockfileresolvedis a full registry tarball URL, even thoughallow-remote=noneis meant to permit registry-mediated tarballs. The standard (hoisted) reifier installs the same dependency fine; only the linked strategy rejects it.Why
Both strategies extract through the same
pacote.extractinreify.js, which exempts registry tarballs from the allow-remote gate via#isRegistryResolvedTarball. That check first requiresnode.isRegistryDependency. In the linked strategy, store nodes areIsolatedNodeinstances — a standalone class that emulateslib/node.jsbut has noisRegistryDependencygetter and no edges to recompute it from. Sonode.isRegistryDependencywasundefined, the exemption short-circuited tofalse, theallowRemote: 'all'override was never applied, and pacote rejected the same-origin registry tarball.This is the second half of the allow-remote registry-tarball handling: the URL-matching half was hardened previously (origin + registry-path-prefix); this fixes the
isRegistryDependencyhalf for the linked path. The origin/path security check still runs unchanged on the linked path — a tampered lockfile pointing at a foreign host is still blocked.How
Carry the registry-dependency flag from the source tree node onto the store node, rather than weakening the guard:
IsolatedNodegains anisRegistryDependencyfield (defaultfalse), settable from constructor options.#externalProxycopiesnode.isRegistryDependencyfrom the real tree node onto the proxy.#generateChildpasses it through to the storeIsolatedNode.This preserves exact parity with the hoisted reifier: registry deps are exempt, user-pinned off-registry URLs are not. It also makes the linked strategy's
isScriptAllowedmatching more accurate — store nodes now carry the trustworthy edge-based flag instead of falling back to guessing registry-ness from the resolved URL.References
Fixes #9494