Walkthrough

This PR replaces pnpr’s mount/router model with registry-based routing. Hosted and upstream registries now declare patterns, routers declare ordered sources, resolution can return Unclaimed, and config, server dispatch, tests, and docs are updated accordingly.

Changes

Registry routing refactor

Estimated code review effort: 5 (Critical) | ~120 minutes

Possibly related PRs

• pnpm/pnpm#12563: Both PRs touch pnpr/crates/pnpr/src/server.rs’s router construction to control dispatch boundaries; this PR switches to registry-graph routing and the retrieved PR adds resolver/registry feature toggles.
• pnpm/pnpm#12593: Both PRs modify pnpr’s tarball-serving path in server.rs; this PR rewires tarball dispatch from the mount graph to the registry graph.
• pnpm/pnpm#12747: This PR continues the same routing-model migration by replacing the mount-based graph, server handlers, and validation introduced in the retrieved PR with registry-based equivalents.

Suggested labels: product: pnpr

Suggested reviewers: juanpicado

• X
• Mastodon
• Reddit
• LinkedIn

• Move package-name pattern declarations from router routes onto concrete mounts.
• Collapse routers into ordered sources: lists with deterministic first-claim resolution.
• Enforce mount namespaces for reads (404) and publishes (400) across all URL paths.

graph TD
  cfg["config.yaml"] --> loader["Config load"] --> mounts["Mounts graph"] --> resolve["Mounts::resolve (enforce patterns)"]
  resolve -->|"Concrete: hosted"| hosted[("Hosted store")]
  resolve -->|"Concrete: upstream"| up{{"Upstream registry"}}
  resolve -->|"Unclaimed"| reject["404 (read) / 400 (publish)"]
  subgraph Legend
    direction LR
    _file["File"] ~~~ _mod["Module"] ~~~ _db[("Database")] ~~~ _ext{{"External"}}
  end

Loading

The following are alternative approaches to this PR:

1. Keep route-level patterns on routers (status quo)

• ➕ Smaller in-memory representation (router owns the matching rules)
• ➕ Potentially simpler mental model if mounts are always used via routers
• ➖ Cannot enforce namespace when mounts are addressed directly (/~/)
• ➖ Allows “dormant” hosted state that could become authoritative after config edits
• ➖ Harder to bound private upstreams against off-scope access via direct mount URLs

2. Duplicate patterns into hosted/uplink tables as well as MountKind

• ➕ May simplify some call sites by reading patterns from serving config directly
• ➕ Could reduce indirection if mounts graph and serving tables drift in responsibilities
• ➖ Creates a consistency problem (two sources of truth for namespace)
• ➖ Increases validation surface and risk of divergence during reloads/overrides

3. Enforce patterns only on publish, not on read resolution

• ➕ Less disruptive change to read paths
• ➕ Smaller behavioral change for existing installations
• ➖ Does not prevent unauthorized reads routed via bounded upstream credentials
• ➖ Still permits serving stored packages that should be out-of-namespace after config changes

Recommendation: Proceed with the PR’s approach: patterns as a single source of truth on concrete mounts, with routers as ordered sources: and enforcement centralized in Mounts::resolve. This yields uniform behavior across direct mount URLs, router URLs, and the path-less base while keeping validation decidable and preventing accidental cross-origin access.

Enhancement (3) +330 / -261

config.rsParse mount-level 'patterns:' and build routers from ordered sources +62/-74

Parse mount-level 'patterns:' and build routers from ordered sources

• Extends YAML shapes for hosted/upstream mounts with 'patterns' and changes router shape to 'sources'. Updates programmatic config builders ('proxy', 'static_serve') and mount graph construction to populate 'MountKind::{Hosted,Upstream}{patterns}' and validate patterns during mount compilation.

pnpr/crates/pnpr/src/config.rs

mount.rsMount namespaces via patterns; routers select first claiming source +213/-145

Mount namespaces via patterns; routers select first claiming source

• Moves patterns onto 'MountKind::{Hosted,Upstream}' and changes routers to ordered 'sources'. Adds 'Resolved::Unclaimed' and enforces namespaces in 'Mounts::resolve' for both direct mounts and routers; updates validation to detect duplicate sources, duplicate mount patterns, unreachable sources, and cross-source pattern shadowing.

pnpr/crates/pnpr/src/mount.rs

server.rsTreat unclaimed packages as definitive 404; reject off-pattern publishes +55/-42

Treat unclaimed packages as definitive 404; reject off-pattern publishes

• Introduces 'MountSource::Unclaimed' and maps 'Resolved::Unclaimed' into read 404 behavior before consulting hosted storage or upstreams. Extends publish target resolution to reject unclaimed names with a clear 400 reason, and simplifies search source selection to router 'sources' ordering.

pnpr/crates/pnpr/src/server.rs

Refactor (1) +1 / -3

lib.rsStop exporting removed Route type +1/-3

Stop exporting removed Route type

• Removes 'Route' from public re-exports to match the new router representation ('sources') and mount-level patterns model.

pnpr/crates/pnpr/src/lib.rs

Tests (5) +371 / -255

tests.rsUpdate config parsing tests for mount patterns and router sources +40/-20

Update config parsing tests for mount patterns and router sources

• Reworks YAML fixtures to use mount-level 'patterns' plus 'router.sources'. Adds coverage for invalid mount patterns and duplicate mount pattern rejection, and updates the misordered-router test to reflect pattern-less catch-all ordering semantics.

pnpr/crates/pnpr/src/config/tests.rs

tests.rsRework mount resolution/validation tests for mount-level namespaces +167/-161

Rework mount resolution/validation tests for mount-level namespaces

• Updates test helpers and cases to reflect 'patterns' on concrete mounts and router 'sources'. Adds tests for direct-mount enforcement (Unclaimed), identical-claim rejection across sources, bidirectional overlap rejection, allowed intra-mount overlap, duplicate mount pattern rejection, and duplicate source rejection.

pnpr/crates/pnpr/src/mount/tests.rs

auth_publish.rsUpdate auth publish test config to router 'sources:' +1/-1

Update auth publish test config to router 'sources:'

• Adjusts the static test config snippet to define a router via 'sources: [local]' instead of route blocks.

pnpr/crates/pnpr/tests/auth_publish.rs

policy.rsUpdate policy test config to router 'sources:' +1/-1

Update policy test config to router 'sources:'

• Rewrites the embedded YAML mounts block to use 'sources: [local]' for router mounts.

pnpr/crates/pnpr/tests/policy.rs

server.rsUpdate server e2e coverage for mount namespaces and ordered sources +162/-72

Update server e2e coverage for mount namespaces and ordered sources

• Migrates router configuration builders to mount-level patterns + ordered sources. Adds e2e assertions that off-pattern reads 404 without hitting upstream (mock expect(0)) and that hosted mount patterns are enforced consistently on direct mount URLs, via routers, and via the path-less base, including publish rejection semantics.

pnpr/crates/pnpr/tests/server.rs

Other (1) +88 / -87

config.yamlMove fixture package patterns onto 'local' mount; routers use 'sources:' +88/-87

Move fixture package patterns onto 'local' mount; routers use 'sources:'

• Updates the bundled example config to declare the registry-mock fixture namespace via 'local.patterns' and collapses the 'main' router to 'sources: [local, npmjs]'. Adds explanatory comments about namespace enforcement and the requirement that pattern-less catch-alls appear last.

pnpr/crates/pnpr/config.yaml

Description

Config::from_yaml_str_with_overrides passes registry.enabled into build_registries as
resolve_upstreams, so --disable-registry leaves Config.upstreams empty even when the resolver is
enabled. The resolver’s RouteHook ignores client-forwarded auth headers and derives server-managed
credentials from Config.upstreams, so private/proxied resolutions will fail (and won’t be
routable/cached correctly).

Code

pnpr/crates/pnpr/src/config.rs[R1520-1526]

+        let mut upstreams: IndexMap<String, UpstreamConfig> = IndexMap::new();
+        let (hosted, registries) = build_registries(
+            &mut upstreams,
+            file.registries,
+            file.default_registry,
+            registry.enabled,
+        )?;

Evidence

The diff shows upstream resolution is gated by registry.enabled, but the resolver always builds a
RouteContext and installs a RouteHook that selects server-managed Authorization headers from
config.upstreams and causes pacquet to ignore client-provided credentials when the hook is
present; therefore an empty config.upstreams under --disable-registry breaks proxied/private
resolution.

pnpr/crates/pnpr/src/config.rs[1502-1526]
pnpr/crates/pnpr/src/config.rs[1724-1781]
pnpr/crates/pnpr/src/route.rs[276-304]
pnpr/crates/pnpr/src/route.rs[596-616]
pnpr/crates/pnpr/src/resolver.rs[188-207]
pacquet/crates/network/src/auth.rs[38-43]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`--disable-registry` is intended to disable serving the npm-registry HTTP surface, but it currently also prevents upstream registry credentials/config from being resolved into `Config.upstreams`. The resolver still installs a route hook that ignores client-forwarded auth and relies on `Config.upstreams` to select server-managed credentials for proxied routes, so private dependency resolution breaks.

### Issue Context
- `Config::from_yaml_str_with_overrides` uses `registry.enabled` to decide whether to resolve upstream registries into `Config.upstreams`.
- `RouteContext::from_config` builds its proxied-alias table from `config.upstreams`.
- The resolver attaches a route hook (`RouteHook`) to `AuthHeaders`, and pacquet’s `AuthHeaders` contract is: when a route hook is present, client credentials are ignored.

### Fix Focus Areas
- pnpr/crates/pnpr/src/config.rs[1502-1526]
- pnpr/crates/pnpr/src/config.rs[1724-1791]

### Proposed fix
- Decouple “serve registry routes” from “resolve upstream configs needed by the resolver’s route hook”.
- Pass `resolve_upstreams = registry.enabled || resolver.enabled` (or an equivalent condition) into `build_registries`, so upstream credentials are resolved whenever the resolver is enabled.
- Optionally update related comments/docs so they don’t claim a resolver-only tier ‘never uses’ upstream secrets, since the route hook can require them.
- Consider updating `ensure_valid_registry_graph` invariants if they currently only require upstream backing config when `registry.enabled` is true, but resolver behavior requires them too.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

RouteContext::classify assumes pnpr’s /~/ URLs are upstream endpoints and returns
RouteClass::Public when ` is not an authorized upstream alias, but /~/` now also serves hosted
registries and routers. That misclassifies private registry endpoints as public, allowing private
packuments to be stored/read from the shared public metadata cache keyspace and then served from
cache without re-checking the registry’s access/masking behavior.

Code

pnpr/crates/pnpr/src/route.rs[R330-347]

+            // A fetch to pnpr's own `/~<name>/` endpoint addresses that
+            // upstream, not a hosted package (a package name can never begin
+            // with `~`). Authorized callers resolve through the upstream;
+            // everyone else — and an unknown upstream — gets an anonymous
       // fetch the endpoint itself rejects, rather than falling through
       // to the hosted-package policy.
       if let Some(rest) = fetch.strip_prefix(hosted)
-                && let Some(uplink) = rest.strip_prefix('~').and_then(|rest| rest.split('/').next())
-                && !uplink.is_empty()
+                && let Some(upstream) =
+                    rest.strip_prefix('~').and_then(|rest| rest.split('/').next())
+                && !upstream.is_empty()
       {
           return match self
               .aliases
               .iter()
-                    .find(|alias| alias.name == uplink && alias.access.allows(identity))
+                    .find(|alias| alias.name == upstream && alias.access.allows(identity))
           {
               Some(alias) => RouteClass::Proxied {
                   alias: alias.name.clone(),

Evidence

The registry model introduced by this PR explicitly defines /~/ as the addressable surface for
hosted registries and routers, but the resolver route classifier continues to treat pnpr-origin
/~/ as an upstream-only endpoint and marks unknown/unauthorized names as Public. Pacquet’s
resolver uses the resulting MetadataCacheScope to pick shared vs private cache namespaces and
serves metadata from cache without a network fetch, so misclassifying a private registry route as
Public can leak private packuments into the shared cache and replay them to other callers.

pnpr/crates/pnpr/src/registry.rs[3-18]
pnpr/crates/pnpr/src/route.rs[317-354]
pnpr/crates/pnpr/src/route.rs[596-633]
pacquet/crates/network/src/auth.rs[63-83]
pacquet/crates/network/src/auth.rs[285-312]
pacquet/crates/resolving-npm-resolver/src/pick_package.rs[373-444]
pacquet/crates/resolving-npm-resolver/src/pick_package.rs[690-713]
pnpr/crates/pnpr/src/route/tests.rs[320-343]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
After this PR, `/~<name>/` is the general **registry endpoint** (hosted, upstream, or router). But `RouteContext::classify()` still treats any pnpr-origin `/~<name>/...` fetch as an “upstream endpoint” lookup and falls back to `RouteClass::Public` when `<name>` is not an authorized upstream alias.
Because `RouteHook::metadata_scope()` maps `RouteClass::Public` to `MetadataCacheScope::Public`, this can place **private registry metadata** into the shared public mirror/cache keyspace. Pacquet’s resolver fast paths can then serve that metadata from memory/disk without an HTTP fetch (and thus without re-checking registry access/masking), creating a cross-caller confidentiality leak and possible authorization bypass on cache hits.
### Issue Context
- `/~<name>/` is now a registry surface for hosted registries and routers, not just upstream aliases.
- `MetadataCacheScope::Public` is explicitly shared across callers; private routes must be partitioned.
### Fix Focus Areas
- Update pnpr-origin `/~<name>/` classification to consult the **registry graph** (and hosted registry access visibility), so hosted/routers (and any private-by-definition endpoint) do **not** fall back to `Public`.
- Introduce/extend a private access descriptor that can namespace cache entries by **(registry id, package)** (or an equivalent unique identifier), so two different hosted registries with the same package name cannot collide.
- Update/replace the existing tests that assert “`/~<name>/` is upstream endpoint, never hosted”.
#### Files/lines to change
- pnpr/crates/pnpr/src/route.rs[317-354]
- pnpr/crates/pnpr/src/route.rs[596-633]
- pnpr/crates/pnpr/src/route/tests.rs[320-343]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Config::ensure_valid_registry_graph folds Config::upstreams into Config::registries via
Registries::ensure_upstream, but ensure_upstream is a no-op when the name already exists as a
non-upstream registry, so programmatic configs can silently keep a Hosted/Router registry under an
upstream’s name. This can route /~/ traffic (and potentially publishes) to the wrong origin while
still carrying upstream serving config under the same identifier, violating the stated “fails closed
like YAML” invariant.

Code

pnpr/crates/pnpr/src/config.rs[R1578-1580]

+        for name in self.upstreams.keys() {
+            self.registries.ensure_upstream(name);
+        }

Evidence

The validation function unconditionally calls ensure_upstream for every upstream key, but
ensure_upstream only inserts when missing and does not validate the existing registry kind; YAML
graph building explicitly rejects such collisions, so programmatic configs can diverge from YAML
invariants.

pnpr/crates/pnpr/src/config.rs[1567-1581]
pnpr/crates/pnpr/src/registry.rs[269-278]
pnpr/crates/pnpr/src/config.rs[1708-1724]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Config::ensure_valid_registry_graph` tries to make programmatic configs fail closed like YAML loads, but it currently does not detect a name collision where `Config::upstreams` contains a key that already exists in the registry graph as a **non-upstream** registry (hosted/router). This leaves ambiguous/incorrect routing for `/~<name>/` and can create unsafe operator/embedder footguns.
### Issue Context
- `ensure_valid_registry_graph` calls `Registries::ensure_upstream(name)` for each upstream key.
- `ensure_upstream` only inserts when the key is missing; it does **not** verify that an existing entry is `Registry::Upstream`.
- YAML loading *does* fail closed on collisions when building the graph.
### Fix Focus Areas
- pnpr/crates/pnpr/src/config.rs[1577-1638]
- pnpr/crates/pnpr/src/registry.rs[269-278]
- pnpr/crates/pnpr/src/config.rs[1708-1724]
### What to change
1. In `Config::ensure_valid_registry_graph`, after (or instead of) `ensure_upstream`, validate that for every `name` in `self.upstreams.keys()`:
- `self.registries.get(name)` is `Some(Registry::Upstream { .. })`.
- If it exists but is `Hosted` or `Router`, return `RegistryError::InvalidConfig` with a collision message (mirroring `build_registries`’ collision failure).
2. (Optional but consistent) Also fail if `self.hosted` contains an entry whose name exists in `self.registries` but is not `Registry::Hosted { .. }`.
### Acceptance criteria
- Programmatic configs cannot have an upstream and a hosted/router registry sharing the same name.
- Behavior matches the YAML collision invariants (fail startup/reload loudly).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

resolve_publish_target returns a 400 for unclaimed names when registry_visible_to_caller(target) is
true, but routers are considered “visible” if any source is visible. This lets a caller distinguish
“unclaimed” (400) from “claimed by an inaccessible hosted source” (404), enabling enumeration of
private scope/package patterns behind an otherwise usable router.

Code

pnpr/crates/pnpr/src/server.rs[R2442-2451]

+        RegistrySource::Unclaimed => {
+            if registry_visible_to_caller(state, identity, &target) {
+                PublishTarget::Reject(format!(
+                    "cannot publish {package:?} {context}: no registry's declared `patterns:` \
+                     claim this package name",
+                ))
+            } else {
+                PublishTarget::NotFound
+            }
+        }

Evidence

The publish routing returns 404 when a name resolves to a hosted registry the caller can’t access,
but returns 400 for Unclaimed when the *router* is deemed visible; since router visibility is
any(source visible), a mixed router yields a 400/404 side-channel for private-pattern membership.

pnpr/crates/pnpr/src/server.rs[2406-2453]
pnpr/crates/pnpr/src/server.rs[2462-2474]
pnpr/crates/pnpr/src/server.rs[1893-1905]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`resolve_publish_target()` returns a detailed 400 rejection for `RegistrySource::Unclaimed` whenever `registry_visible_to_caller()` returns true. For routers, `registry_visible_to_caller()` currently returns true if **any** source is visible, which makes a router with mixed visibility leak whether a probed package name is claimed by a hidden hosted registry (404) vs truly unclaimed (400).
## Issue Context
This leak matters specifically when a router is usable/visible via at least one public source (often an upstream), but also contains at least one hosted source hidden by its access list. A caller who can reach the publish endpoint can then probe names and infer private pattern membership.
## Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[2406-2475]
Suggested direction:
- Change router visibility for the purpose of emitting the detailed `Unclaimed` rejection so that a router is considered “visible” only when **all** its concrete sources are visible to the caller (or at minimum, all hosted sources are visible). This makes `Unclaimed` return 404 in mixed-visibility routers, removing the oracle.
- Keep current behavior for concrete registries (hosted/upstream) as-is.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Path-less packument/version handlers resolve the default registry and package twice (serve_*
resolves via resolve_registry_source, then private_if_caller_gated re-resolves to decide cache
headers), adding avoidable CPU work and String allocations on the hot install path. This is
especially wasteful under load because every GET /<pkg> and GET /<pkg>/<version> does the extra
resolution even when the response is already determined.

Code

pnpr/crates/pnpr/src/server.rs[R1799-1806]

if acl_gated {
return private_no_cache(response);
}
-    match default_target_mount(state) {
+    match default_registry_target(state) {
Some(target) if resolves_to_private_source(state, &target, package) => {
private_no_cache(response)
}
_ => response,

Evidence

The path-less handlers first pick a default target and serve via registry dispatch; cache header
logic then re-fetches the default target and re-runs resolution/privacy checks, causing duplicated
work per request.

pnpr/crates/pnpr/src/server.rs[1115-1131]
pnpr/crates/pnpr/src/server.rs[1744-1785]
pnpr/crates/pnpr/src/server.rs[1796-1807]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The path-less handlers (e.g. `serve_packument`, `serve_version_manifest`) already route through the registry graph to serve the response, but then `private_if_caller_gated` calls `default_registry_target` + `resolves_to_private_source` which calls `resolve_registry_source` again. This duplicates routing/pattern checks and performs additional `String` allocations on a hot request path.
### Issue Context
This impacts the path-less base (`https://<pnpr>/...`) which is described in-code as “the hot install path”, so even small inefficiencies can show up in throughput/latency under load.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[1115-1155]
- pnpr/crates/pnpr/src/server.rs[1744-1807]
### Suggested fix approach
- Thread the already-chosen default target (and/or the already-resolved `RegistrySource`) through the path-less serving flow so cacheability can be decided without re-resolving.
- Option A (minimal): change `private_if_caller_gated` to accept `default_target: &str` so it doesn’t call `default_registry_target` again.
- Option B (better): have `serve_registry_packument` / `serve_registry_version_manifest` return `(Response, bool caller_gated_source)` (or a small struct) computed from the same `RegistrySource` match, and let the path-less wrapper apply `private_no_cache` based on that flag + per-package ACL, avoiding the second `resolve_registry_source` call entirely.
- Also consider returning borrowed registry ids from `resolve_registry_source` (or using `Cow<'a, str>`) to avoid per-request `to_string()` where ownership isn’t required.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Requests routed to a private upstream registry return 403 on access denial, while unknown registries
return 404, letting an attacker probe /~<name>/ to enumerate private upstream registry IDs (for
package names claimed by that registry’s patterns). This contradicts the code comment that private
registry names are "carefully mask[ed]" and creates an existence oracle.

Code

pnpr/crates/pnpr/src/server.rs[R1745-1764]

+fn resolve_registry_source(state: &AppState, registry: &str, package: &str) -> RegistrySource {
+    match state.inner.config.registries.resolve(registry, package) {
+        Resolved::Concrete { registry, kind: ConcreteKind::Upstream } => {
+            RegistrySource::Upstream(registry.to_string())
}
-        Resolved::Concrete { mount, kind: ConcreteKind::Hosted } => {
-            MountSource::Hosted(mount.to_string())
+        Resolved::Concrete { registry, kind: ConcreteKind::Hosted } => {
+            RegistrySource::Hosted(registry.to_string())
}
-        // A router that matched no route is a definitive not-found — never a
-        // fall-through to another origin.
-        Resolved::NoRoute => MountSource::NotFound,
-        // Every configured uplink is an upstream mount addressable at
+        // An unclaimed name is definitive — never a fall-through to another
+        // origin, and never a storage or upstream consultation.
+        Resolved::Unclaimed => RegistrySource::Unclaimed,
+        // Every configured uplink is an upstream registry addressable at
// `/~<uplink>/`, even one inserted programmatically without rebuilding
-        // the mount graph; fall back to that before declaring not-found.
-        Resolved::UnknownMount => {
-            if state.inner.config.uplinks.contains_key(mount) {
-                MountSource::Upstream(mount.to_string())
+        // the registry graph; fall back to that before declaring not-found.
+        Resolved::UnknownRegistry => {
+            if state.inner.config.uplinks.contains_key(registry) {
+                RegistrySource::Upstream(registry.to_string())
} else {
-                MountSource::NotFound
+                RegistrySource::NotFound
}

Evidence

The router code comment states that differing auth vs not-found responses would create an existence
oracle for private registry names. However, authorized_uplink explicitly returns a 403 Forbidden
when access denies the caller, and resolve_registry_source routes requests to upstream
registries, making the 403 observable and distinguishable from unknown registries (404).

pnpr/crates/pnpr/src/server.rs[294-299]
pnpr/crates/pnpr/src/server.rs[1229-1259]
pnpr/crates/pnpr/src/server.rs[1745-1766]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Private upstream registries currently return a different HTTP status for “exists but access denied” (403) vs “registry id does not exist” (404). With the new registry routing (`resolve_registry_source`), this becomes a stable existence oracle for private upstream registry IDs (for any package name that is within the registry’s declared `patterns:`).
### Issue Context
- The server explicitly avoids creating a 401-vs-404 oracle in the identity endpoints, stating that content handlers “carefully mask” private registry names.
- `authorized_uplink()` returns a `RegistryError::Forbidden` response when the registry’s `access:` policy denies the caller.
- `resolve_registry_source()` routes `/~<name>/...` to upstream registries (including private ones), so this 403 is observable at the public registry surface.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[1745-1766]
- pnpr/crates/pnpr/src/server.rs[1229-1259]
- pnpr/crates/pnpr/src/server.rs[294-299]
### Suggested fix
- For upstream registries with `access:` (private upstreams), return `404 Not Found` (same as unknown registry) when the caller is not admitted, matching the hosted-registry masking behavior.
- Keep observability by logging the denied access (server-side), but do not reveal it via status code.
- Add/adjust an e2e test asserting that denied access to a private upstream via `/~<name>/...` is indistinguishable from an unknown registry (status and body), for an in-pattern package name.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The rustdoc for authorized_upstream claims an upstream "with no access: policy" is a 404, but
the implementation treats access: None as public/reachable and only gates when access is
present. This mismatch can mislead future changes around upstream visibility and masking semantics.

Code

pnpr/crates/pnpr/src/server.rs[R1232-1236]

+/// Resolve the upstream behind an authorized `/~<name>/` endpoint request.
///
-/// Fails closed: an uplink that does not exist or carries no `access:` policy
+/// Fails closed: an upstream that does not exist or carries no `access:` policy
/// is a `404` (it is not a private-route endpoint), and a caller the policy
/// does not admit is a `403`. Returns the [`Upstream`] to fetch *through* —
-/// `/~<uplink>/` requests never read or write the shared proxy mirror, so a
-/// private uplink's packuments and tarballs can never leak across the public
-/// path or another uplink.
-fn authorized_uplink<'a>(

Evidence

The doc states lack of access: causes a 404, but the code path only checks access when present
and otherwise proceeds, explicitly commenting that public upstreams (no access) are reachable.

pnpr/crates/pnpr/src/server.rs[1232-1253]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`authorized_upstream`'s docstring contradicts its behavior: the code allows `access=None` (public upstream) but the doc says that case 404s.
### Issue Context
This function is used broadly for `/~<name>/` upstream serving and router resolution; documenting the correct semantics matters to avoid accidental security/behavior regressions later.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[1232-1263]
### Suggested fix approach
- Update the doc to reflect actual semantics (e.g. “unknown upstream is 404; if `access` is set and denies the caller, return 403; `access=None` means public”).
- Alternatively, if the doc reflects intended behavior, change implementation accordingly (but that would be a behavior change and should be justified/tested).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

upstream_cache_namespace clones the cached namespace String on every upstream packument/tarball
request, adding avoidable heap allocations on a hot path. The namespace can be returned as a borrow
(or Cow) because it is stored in AppInner and lives long enough across awaits.

Code

pnpr/crates/pnpr/src/server.rs[R1269-1275]

+fn upstream_cache_namespace(state: &AppState, upstream: &str) -> String {
state
.inner
-        .uplink_cache_namespaces
-        .get(uplink)
+        .upstream_cache_namespaces
+        .get(upstream)
.cloned()
-        .unwrap_or_else(|| compute_uplink_cache_namespace(&state.inner.config, uplink))
+        .unwrap_or_else(|| compute_upstream_cache_namespace(&state.inner.config, upstream))

Evidence

The helper clones the namespace string, and it is used in upstream packument loads on each request,
so the clone happens per request in upstream-proxy traffic.

pnpr/crates/pnpr/src/server.rs[1265-1276]
pnpr/crates/pnpr/src/server.rs[1451-1461]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`upstream_cache_namespace` currently does `.cloned()` from `AppInner::upstream_cache_namespaces`, allocating a new `String` per request. This helper is called on every upstream packument/tarball serve, so this adds allocator/CPU overhead on a hot path.
### Issue Context
Callers only need an `&str` namespace to pass into storage/cache helpers; the namespace is already stored in `AppInner`.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[1265-1276]
- pnpr/crates/pnpr/src/server.rs[1451-1463]
### What to change
- Change `upstream_cache_namespace` to return `Cow<'a, str>` (or `&'a str` if you’re comfortable removing the fallback path).
- `Cow::Borrowed(ns)` when present in `upstream_cache_namespaces`.
- `Cow::Owned(compute_upstream_cache_namespace(...))` only in the (should-not-happen) fallback.
- Update call sites to pass `namespace.as_ref()`.
### Acceptance criteria
- No per-request `String` clone on cache-hit paths.
- Behavior unchanged for fallback computation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.