allow-remote should preserve path boundaries for path-qualified registries

[Abhinav-143x]

Summary

--allow-remote=none should allow tarballs that are genuinely served by the configured registry, but it should preserve the path boundary for path-qualified registries.

Today the registry tarball exception can treat a same-origin tarball outside the configured registry path as registry-provided.

For example:

• configured registry: https://registry.example.com/npm/
• lockfile tarball URL: https://registry.example.com/evil/pkg-1.0.0.tgz

Those are the same origin, but the tarball is outside the configured /npm/ registry path.

Why this matters

Path-qualified registries are common for private registry deployments and for npm auth scoping. npm's own .npmrc docs support path-scoped auth entries, and registry products commonly expose separate repositories under different paths on the same host.

When --allow-remote=none is used as an install-source restriction, a path-qualified registry should not allow an arbitrary sibling path on the same origin to satisfy the registry tarball exception.

Proposed fix

PR #9473 tightens the registry tarball exception so it requires:

• same origin; and
• the resolved tarball pathname to stay under the configured registry pathname, unless the configured registry is root-scoped.

Root-scoped registries have no path boundary to enforce, so origin match remains sufficient there.

Related

• Fix PR: fix: validate registry path for allow-remote tarball exception #9473
• Adjacent context: [BUG] allow-remote=none breaks pure-registry installs #9347 and fix: Enforce allow-git/allow-file/allow-directory/allow-remote configs at the arborist resolution layer #9348