Is there an existing issue for this?
This issue exists in the latest npm version
This is not just a request to bump a dependency for a CVE
Current Behavior
If a registry is serving tarballs from a different path than the actual registry metadata (such as https://registry.example.com/blob/package.tgz, while the registry is https://registry.example.com/npm) this results in EALLOWREMOTE attempting to install anything from it.
Despite these ostensibly being the same origin to most browsers, as both the hostname and protocol match, npm apparently wants registry= to be an exact prefix for the purposes of allow-remote=none, yet I can't find anywhere that expectation is documented.
Expected Behavior
One of the following:
NPM follows browser rules, and understands that if the hostname and protocol match, the URL is indeed from the configured registry.
The expectation that tarballs are hosted/proxied from a path under the root of the registry, if the registry is not already the root of the site, is documented somewhere easily accessible.
Steps To Reproduce
- Set up a registry that serves tarballs from a different directory on the same hostname (such as aliasing two different paths to the same registry instance with a reverse proxy? the actual registry in question has something similar, though I'm not in a position to know the exact config behind it)
- Point NPM at the "non-canonical" registry path (so that the returned
tarball path isn't underneath it)
- Run
npm install, get EALLOWREMOTE.
Environment
- npm: 12.0.1
- Node.js: 24.18.0
- OS Name: MacOS
- System Model Name: Macbook Pro
- npm config: (Actual registry URL redacted for privacy, but the paths are accurate)
; "user" config from /Users/<redacted>/.npmrc
<redacted auth tokens>
; registry = "https://registry.example.com/api/npm/npm" ; overridden by project
; "project" config from /Users/<redacted>/<redacted>/.npmrc
registry = "https://registry.example.com/api/npm/npm" ; The same one as above
The registry itself is a JFrog Artifactory instance I'm not in a position to know any precise details about, with the actual paths involved being /api/npm/npm (The one in all our documentation and configs) and /artifactory/api/npm/npm (the one that the tarballs resolve under). Changing our config to use the more cumbersome path 'fixes' the issue, but is somewhat annoying if we have to rewrite everything just because someone decided that folders should be trust boundaries now.
Is there an existing issue for this?
This issue exists in the latest npm version
This is not just a request to bump a dependency for a CVE
Current Behavior
If a registry is serving tarballs from a different path than the actual registry metadata (such as
https://registry.example.com/blob/package.tgz, while the registry ishttps://registry.example.com/npm) this results in EALLOWREMOTE attempting to install anything from it.Despite these ostensibly being the same origin to most browsers, as both the hostname and protocol match, npm apparently wants
registry=to be an exact prefix for the purposes ofallow-remote=none, yet I can't find anywhere that expectation is documented.Expected Behavior
One of the following:
NPM follows browser rules, and understands that if the hostname and protocol match, the URL is indeed from the configured registry.
The expectation that tarballs are hosted/proxied from a path under the root of the registry, if the registry is not already the root of the site, is documented somewhere easily accessible.
Steps To Reproduce
tarballpath isn't underneath it)npm install, get EALLOWREMOTE.Environment
The registry itself is a JFrog Artifactory instance I'm not in a position to know any precise details about, with the actual paths involved being
/api/npm/npm(The one in all our documentation and configs) and/artifactory/api/npm/npm(the one that the tarballs resolve under). Changing our config to use the more cumbersome path 'fixes' the issue, but is somewhat annoying if we have to rewrite everything just because someone decided that folders should be trust boundaries now.