• Create PR with unit tests
• Commit unit tests in branch pnpr-mount

Description

is_safe_path_segment() is documented to reject “absolute-path prefixes” but only delegates to
is_safe_segment() (separator checks) and does not enforce prefix/absolute-component rejection.
Because /~//-/ may use an upstream-controlled tarball basename (via rewrite_tarball_urls) and
the cache path is later built with PathBuf::join(filename), this can produce cache paths outside
the intended directory on platforms with path-prefix components (notably Windows).

Code

pnpr/crates/pnpr/src/package_name.rs[R86-95]

+/// Whether `filename` is safe to use as a single on-disk path segment (no
+/// traversal, no separators, no absolute-path prefixes). The uplink tarball
+/// path uses it to admit a non-canonical basename preserved from an upstream
+/// `dist.tarball` (see `rewrite_tarball_urls`) into the cache layout — the
+/// packument match is what authorizes the name; this only keeps it on disk
+/// safely.
+#[must_use]
+pub fn is_safe_path_segment(filename: &str) -> bool {
+    is_safe_segment(filename)
+}

Evidence

The code rewrites upstream dist.tarball to a pnpr-served URL using the upstream URL’s basename,
then later accepts that basename (when non-canonical) using is_safe_path_segment() and joins it
into an on-disk path; the helper does not actually enforce its own “no absolute-path prefixes”
guarantee.

pnpr/crates/pnpr/src/package_name.rs[77-95]
pnpr/crates/pnpr/src/upstream.rs[374-399]
pnpr/crates/pnpr/src/server.rs[1402-1421]
pnpr/crates/pnpr/src/storage.rs[655-665]

Agent prompt

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

## Issue description
`is_safe_path_segment()` claims to reject absolute-path prefixes but currently only checks for `/` and `\\` (via `is_safe_segment`). This is insufficient for filesystem safety on platforms that have path-prefix components (e.g., Windows drive/prefix components). The server uses this function to accept upstream-controlled non-canonical tarball basenames and then joins them into on-disk cache paths.
### Issue Context
- Upstream tarball basenames are preserved and rewritten into pnpr-served URLs.
- When a client requests that URL, pnpr accepts the basename (if `is_safe_path_segment` passes) and later builds a cache path with `PathBuf::join(filename)`.
### Fix Focus Areas
- pnpr/crates/pnpr/src/package_name.rs[77-95]
### What to change
- Replace `is_safe_path_segment()` with a stricter check based on `std::path::Path::components()`.
- Require the path to consist of exactly one `Component::Normal(_)`.
- Reject any `Component::Prefix(_)`, `RootDir`, `ParentDir`, or `CurDir` components.
- Keep the existing `/`, `\\`, leading-dot, NUL checks as additional defense.
- Add unit tests covering:
- `".."`, `"."`, `"a/b"`, `"a\\b"`, `"\\\\server"` rejected
- Windows-prefix-shaped strings like `"C:foo.tgz"` / `"C:\\foo.tgz"` rejected (gate with `cfg(windows)` where appropriate)
This preserves the feature (supporting non-canonical upstream basenames) while restoring the intended filesystem-safety contract.

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

Description

build_mounts() accepts mount ids as arbitrary YAML map keys without validating they are safe URL
path segments. A mount id containing '/', '.'/'..', or other path-meaningful characters can become
unreachable or path-normalized by intermediaries, undermining the mount boundary and routing
invariants.

Code

pnpr/crates/pnpr/src/config.rs[R1616-1624]

+    for (name, file) in mount_files {
+        if graph.contains_key(&name) {
+            return Err(RegistryError::InvalidConfig {
+                reason: format!(
+                    "mount {name:?} collides with another mount or uplink of the same name",
+                ),
+            });
+        }
+        match file {

Evidence

The config builder iterates mount_files and inserts mount ids into the mount graph with only a
collision check, but mount ids are later taken from request path segments and interpolated into
/~{mount} URL bases. Without validating that mount ids are safe single path segments, malformed
ids can’t be addressed correctly and can create path-confusion issues.

pnpr/crates/pnpr/src/config.rs[1604-1659]
pnpr/crates/pnpr/src/server.rs[530-546]
pnpr/crates/pnpr/src/server.rs[911-916]

Agent prompt

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

## Issue description
`mounts:` keys (mount ids) are later used as literal URL path segments (`/~<mount>/` and tarball rewrite bases), but `build_mounts()` only checks name collisions and never validates that the mount id is a safe, non-empty single path segment. This allows configs that create unreachable mounts (e.g. ids containing `/`) or path-confusing mounts (e.g. `.`/`..`), which can break the new routing model’s invariants.
### Issue Context
- Mount ids are extracted from the request path and used to construct `tarball_base` strings.
- The config loader already validates hosted `org` because it becomes a filesystem/object-store segment; mount ids deserve analogous validation because they become URL path segments.
### Fix Focus Areas
- pnpr/crates/pnpr/src/config.rs[1604-1663]
- pnpr/crates/pnpr/src/config/tests.rs[1-260]
### Suggested fix approach
1. Add a `validate_mount_id(name: &str) -> Result<(), RegistryError>` helper.
2. Call it for:
- every `mount_files` key before inserting into `graph`
- every pre-existing `uplinks` key that is treated as an addressable mount
- (optionally) `defaultTarget` value (in addition to the existing “must exist” check)
3. Enforce at minimum:
- non-empty
- no `/` or `\\`
- not `.` or `..`
- (recommended) disallow `%` and `?`/`#` to prevent decoded/fragment/query confusion
4. Add/extend config tests to assert invalid mount ids fail config load with a clear error.

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

Description

Mounts::validate_router only rejects a route when *all* its patterns are shadowed by earlier
routes, so a route mixing a shadowed private pattern with any unshadowed pattern validates and then
silently misroutes the shadowed packages to the earlier route. This breaks the PR’s “misordered
routes fail closed” guarantee and can reintroduce dependency-confusion-style misrouting (e.g.
@private/* shadowed by an earlier @*/* route, while the same route also contains an unshadowed
unscoped pattern).

Code

pnpr/crates/pnpr/src/mount.rs[R325-333]

+            // A route is unreachable when every one of its patterns is already
+            // covered by some pattern in an earlier route — the misordered-`**`
+            // hazard and its general form. Reject it so a shadowed private route
+            // is a startup error, not a silent public fall-through.
+            if route
+                .patterns
+                .iter()
+                .all(|pattern| seen_patterns.iter().any(|earlier| earlier.covers(pattern)))
+            {

Evidence

The validation comment states it intends to reject shadowed private routes at startup, but the
implementation uses all(...), which only fails when every pattern in the route is covered—so a
shadowed subset can remain undetected and misroute at runtime.

pnpr/crates/pnpr/src/mount.rs[325-339]
pnpr/crates/pnpr/src/mount.rs[15-26]

Agent prompt

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

## Issue description
`Mounts::validate_router` treats a route as unreachable only if **all** patterns in that route are covered by earlier patterns. This allows **partially shadowed** patterns to slip through validation, even though those specific patterns are dead and will route to earlier mounts at runtime.
## Issue Context
This is a security-relevant validation bug because operators can group multiple patterns into a single route to one source. If a private pattern inside that route is shadowed (misordered), pnpr will still start and route those packages to the earlier route.
## Fix Focus Areas
- pnpr/crates/pnpr/src/mount.rs[325-339]
## Suggested fix
- Change validation to fail if **any** pattern in `route.patterns` is already covered by `seen_patterns`.
- E.g. before the `all(...)` check, loop each `pattern` and if `seen_patterns.iter().any(|earlier| earlier.covers(pattern))` then return a new error like `MountConfigError::ShadowedPattern { router, index, pattern: pattern.to_string() }`.
- Alternatively, treat this as an `UnreachableRoute` but include which pattern is shadowed in the error message.
- Add tests covering the partially-shadowed case (one shadowed pattern + one unshadowed pattern in the same route).

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

Description

load_uplink_packument logs upstream failures with ?err (Debug), which can include full upstream
URLs and leak embedded credentials into logs when stale-cache fallback triggers. This bypasses the
codebase’s own redaction path (RegistryError::log_message).

Code

pnpr/crates/pnpr/src/server.rs[R1049-1053]

+                tracing::warn!(
+                    ?err,
+                    package = %name.as_str(),
+                    "upstream packument refetch failed; serving stale cache",
+                );

Evidence

The new stale-cache fallback logs ?err, which uses Debug formatting, while the error type
provides a dedicated redaction helper (log_message) for safe logging. This mismatch can leak
credential-bearing URL data in the warn log path.

pnpr/crates/pnpr/src/server.rs[1039-1054]
pnpr/crates/pnpr/src/error.rs[216-233]
pnpr/crates/pnpr/src/error.rs[276-279]

Agent prompt

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

## Issue description
`load_uplink_packument` emits `tracing::warn!(?err, ...)` when an upstream refetch fails and the server serves stale cache. Using `?err` logs the `Debug` representation of `RegistryError`, which can include sensitive data (notably upstream URLs with embedded credentials), bypassing the existing redaction helper.
### Issue Context
The codebase already defines `RegistryError::log_message()` to redact URL credentials before logging. This callsite should use that redacted representation (or log structured non-sensitive fields) instead of `Debug`.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[1039-1055]
- pnpr/crates/pnpr/src/error.rs[216-279]
### Suggested fix
- Replace `tracing::warn!(?err, ...)` with a redacted/string form, e.g.:
- `let err_msg = err.log_message(); tracing::warn!(err=%err_msg, error_kind=%err.log_kind(), package=%name.as_str(), "...");`
- Avoid `?err` for error types that may carry URLs/credentials.

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

Description

build_mounts allows multiple hosted mounts to reuse the same org namespace while access policy
is per-mount, but storage namespacing is only by org. Two mounts with different access policies
but the same org will share the same storage keyspace, so data can be exposed via the
more-permissive mount or overwritten cross-mount.

Code

pnpr/crates/pnpr/src/config.rs[R1626-1632]

+                validate_org_namespace(&name, &mount.org)?;
+                let access = mount
+                    .access
+                    .as_ref()
+                    .map_or_else(|| AccessList::parse("$all"), AccessSpec::to_access_list);
+                hosted.insert(name.clone(), HostedConfig { org: mount.org, access });
+                graph.insert(name, MountKind::Hosted);

Evidence

build_mounts inserts hosted mounts keyed by mount id but stores the namespace as a raw org
string without checking for duplicates; storage namespacing then uses that org string as the
namespace prefix for both filesystem and S3 backends, so identical org values collide.

pnpr/crates/pnpr/src/config.rs[1604-1633]
pnpr/crates/pnpr/src/storage.rs[303-312]
pnpr/crates/pnpr/src/s3.rs[144-163]

Agent prompt

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

## Issue description
Hosted mounts are intended to have isolated storage namespaces, but the config loader currently allows multiple hosted mounts to specify the same `org`. Because `Storage::for_hosted(org)` and `S3Store::namespaced(org)` derive the namespace solely from `org`, two mounts can unintentionally share the same on-disk/object-key prefix while having different access policies, enabling cross-mount reads or overwrites.
### Issue Context
- `build_mounts` validates `org` for path-safety but does not ensure uniqueness.
- Storage namespacing is derived only from `org`.
### Fix Focus Areas
- pnpr/crates/pnpr/src/config.rs[1604-1647]

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

Description

load_uplink_packument serves cached packument bytes on *any* upstream fetch error (including
authoritative 401/403/429), so pnpr can keep serving stale upstream metadata even when the upstream
is explicitly denying the request. This also hides real auth/rate-limit failures behind stale
content, conflicting with the codebase’s own rule that only availability failures are eligible for
fallthrough-like behavior.

Code

pnpr/crates/pnpr/src/server.rs[R996-1016]

+    let fetched = match upstream.fetch_packument(name, &CacheValidators::default()).await {
+        Ok(fetched) => fetched,
+        // Stale-if-error: a stale entry is refetched, but if the upstream is
+        // unreachable, serve the last cached body for this same origin rather
+        // than failing. This preserves availability during a transient outage
+        // and is not a cross-origin fall-through — the bytes came from this very
+        // mount. A clean `NotFound` is an `Ok` variant below, so it never lands
+        // here and stays an authoritative 404.
+        Err(err) => {
+            if upstream.caches()
+                && let Some(bytes) =
+                    state.inner.storage.read_uplink_packument_any(namespace, name).await?
+            {
+                tracing::warn!(
+                    ?err,
+                    package = %name.as_str(),
+                    "upstream packument refetch failed; serving stale cache",
+                );
+                return Ok(Some(bytes));
+            }
+            return Err(err);

Evidence

The new stale-if-error path returns cached bytes on any fetch error, but upstream 4xx responses are
modeled as errors (UpstreamStatus) and are explicitly documented as non-retryable/non-maskable.
Therefore, the current implementation will incorrectly serve stale cache on auth/rate-limit
failures.

pnpr/crates/pnpr/src/server.rs[984-1017]
pnpr/crates/pnpr/src/upstream.rs[324-341]
pnpr/crates/pnpr/src/error.rs[216-235]

Agent prompt

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

## Issue description
`load_uplink_packument()` currently falls back to `read_uplink_packument_any()` on *any* `Err(err)` from `upstream.fetch_packument(...)`. Because upstream non-success statuses (including 4xx like 401/403/429) are represented as `RegistryError::UpstreamStatus`, this logic masks authoritative upstream denials and can continue serving cached private metadata after upstream access is revoked.
### Issue Context
The repo already encodes the intended policy in `RegistryError::allows_uplink_fallthrough()`: only availability errors (transport errors, open circuit breaker, or 5xx) are eligible; 4xx must surface immediately.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[984-1017]
### Suggested fix
- Change the stale-if-error branch to only serve stale bytes when the error is an availability failure.
- e.g. `if err.allows_uplink_fallthrough() { ... serve stale ... } else { return Err(err); }`
- Specifically, *do not* serve stale bytes for `RegistryError::UpstreamStatus { status: 4xx, .. }`.
- Optional hardening: avoid logging `?err` directly in this path, since `UpstreamStatus` carries the upstream response body; log only `status`/`url` (or a redacted form) to reduce risk of sensitive/large-body log spam.

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

Description

load_uplink_packument treats stale cached packuments as a miss and immediately refetches; when the
upstream is unreachable, requests fail even though cached bytes still exist on disk. This creates
avoidable outages (and repeated upstream load) for hot packages once their TTL expires.

Code

pnpr/crates/pnpr/src/storage.rs[R492-494]

+            // Stale: treated as a miss so the caller refetches from the upstream
+            // (there is no conditional revalidation), so the body isn't read here.
+            Ok(Some(CachedPackument::Stale))

Evidence

The storage layer explicitly treats TTL-expired cache entries as a miss and does not read the cached
body, and the server read path only serves cached bytes on the fresh-hit path (otherwise it
refetches from upstream). With this combination, a transient upstream failure after TTL expiry
produces an error even though the bytes are still present on disk.

pnpr/crates/pnpr/src/storage.rs[475-495]
pnpr/crates/pnpr/src/server.rs[980-1018]

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 per-mount uplink packument cache marks TTL-expired entries as `Stale` and does not read their body. As a result, `load_uplink_packument()` always refetches when TTL has expired, and if that refetch fails (transient network / upstream outage), pnpr returns an error despite having usable cached bytes on disk.
### Issue Context
This is a hot path for `/~<mount>/...` packument and version-manifest reads. Restoring a "stale-if-error" fallback preserves availability during transient upstream failures without reintroducing cross-origin fall-through.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[984-1019]
- pnpr/crates/pnpr/src/storage.rs[475-495]
### Suggested fix
In `load_uplink_packument`:
- Keep the current behavior for fresh cache hits.
- On cache miss due to staleness, attempt `upstream.fetch_packument(...)`.
- If the fetch fails with a *transport/unavailability* error, fall back to `state.inner.storage.read_uplink_packument_any(namespace, name)` and serve it when present (optionally log/tag the request span as `cache="stale"`).
- Do **not** serve stale bytes when the upstream returns a clean `NotFound` (that should remain an authoritative 404 for this origin).

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

Description

Mount-served read handlers call per-package authorize() before enforcing hosted-mount visibility
(readable_hosted_namespace), so callers without org access can receive 401/403 instead of the
intended 404 masking for private hosted orgs. This leaks information via status-code differences on
packument/tarball/version-manifest paths when package policies deny Access.

Code

pnpr/crates/pnpr/src/server.rs[R1272-1279]

+    // The per-package access ACL applies to every mount-served read, regardless
+    // of whether the package routes to a hosted org or an upstream, so an
+    // access-gated name can't be read through a public upstream. Enforced here
+    // (before resolving the source) so the access decision precedes any
+    // existence-revealing signal like an OSV 403.
if let Err(err) = authorize(state, identity, name.as_str(), Action::Access) {
return error_response(&err);
}
-    if let Err(err) = ensure_osv_allowed(state, &name, &name_version) {
-        return error_response(&err);
-    }
-
-    // The hosted store is authoritative. A genuine fault here (not a
-    // plain miss, which surfaces as `Ok(None)`) must fail closed rather
-    // than fall through to upstream and serve bytes of a different
-    // provenance for the same package name.
-    match state.inner.storage.open_hosted_tarball(&name, &filename).await {
-        Ok(Some((body, len))) => return tarball_response(body, len),
-        Ok(None) => {}
-        Err(err) => {
-            tracing::warn!(?err, package = %name.as_str(), %filename, "hosted tarball open failed");
-            return error_response(&err);

Evidence

The mount dispatch path runs authorize() before it can know whether the request resolves to a hosted
mount whose org access should be masked as 404, while the masking is implemented later via
readable_hosted_namespace(). Since authorize() can return Unauthenticated/Forbidden, it can surface
401/403 before the 404 mask is applied.

pnpr/crates/pnpr/src/server.rs[1260-1293]
pnpr/crates/pnpr/src/server.rs[842-874]
pnpr/crates/pnpr/src/server.rs[1330-1342]
pnpr/crates/pnpr/src/server.rs[2940-2966]

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 hosted orgs are intended to hide existence by returning `404` to callers who lack org access. However, in the mount-dispatch read paths, `authorize(..., Action::Access)` runs *before* the hosted-org visibility gate (`readable_hosted_namespace`). If the per-package ACL denies access, the handler returns `401/403` immediately, bypassing the hosted-org masking.
### Issue Context
- `serve_mount_packument` (and similarly `serve_mount_tarball` / `serve_mount_version_manifest`) does `authorize()` before `resolve_mount_source()`.
- The hosted-org visibility gate lives in `readable_hosted_namespace()` and is only applied *after* resolution to a hosted mount.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[1260-1324]
- pnpr/crates/pnpr/src/server.rs[842-882]
### Suggested fix
1. In mount-dispatch read paths, resolve the mount source first.
2. If the resolved source is `Hosted`, check `readable_hosted_namespace(...)` and immediately return `not_found()` on `None` **before** calling `authorize()`.
3. Only after passing the hosted-org gate, apply `authorize()` and proceed with packument/tarball/version-manifest loading.
This preserves the desired 404 masking for private hosted orgs while still enforcing per-package ACLs for callers who are allowed to see the org.

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

Description

uplink_cache_namespace() derives a private upstream mount’s cache namespace from only the
Authorization header, so mounts whose effective credential is supplied via other headers will reuse
the same cache across credential rotations. This can keep serving packuments/tarballs fetched under
the old credential (wrong visibility/content) until entries expire or are purged.

Code

pnpr/crates/pnpr/src/server.rs[R957-969]

fn uplink_cache_namespace(state: &AppState, uplink: &str) -> String {
-    let authorization = state
-        .inner
-        .config
-        .uplinks
-        .get(uplink)
-        .and_then(|uplink| uplink.headers.get(reqwest::header::AUTHORIZATION))
-        .and_then(|value| value.to_str().ok())
-        .unwrap_or_default();
-    let digest = crate::route::uplink_cache_digest(
-        uplink,
-        crate::route::credential_digest(authorization),
-        &state.inner.config.resolution_cache_secret,
-    );
-    format!("~uplinks/{digest}")
+    let config = state.inner.config.uplinks.get(uplink);
+    if config.is_some_and(|uplink| uplink.access.is_some()) {
+        let credential = config
+            .and_then(|uplink| uplink.headers.get(reqwest::header::AUTHORIZATION))
+            .and_then(|value| value.to_str().ok())
+            .unwrap_or_default();
+        let digest = crate::route::uplink_cache_digest(
+            uplink,
+            crate::route::credential_digest(credential),
+            &state.inner.config.resolution_cache_secret,
+        );
+        return format!("~uplinks/{digest}");

Evidence

The private-cache namespace is computed from only the Authorization header value, but the config
layer explicitly supports credentials via arbitrary custom headers (e.g. API keys). Therefore
credential rotation via custom headers won’t change the namespace, leaving prior cached content
reachable via the new config.

pnpr/crates/pnpr/src/server.rs[943-974]
pnpr/crates/pnpr/src/config.rs[474-517]
pnpr/crates/pnpr/src/config.rs[559-562]

Agent prompt

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

## Issue description
`uplink_cache_namespace()` currently computes the *private* upstream cache namespace using only the `Authorization` header value. However, pnpr explicitly supports credentials in **custom headers** for uplinks/upstream mounts, so rotating such a credential will not change the cache namespace and can continue serving content fetched with the previous credential.
### Issue Context
- Private upstream mount cache namespaces are intended to rotate when the upstream credential rotates.
- `UplinkConfig.headers` is the merged set of auth-derived + custom headers.
### Fix Focus Areas
- pnpr/crates/pnpr/src/server.rs[943-974]
- pnpr/crates/pnpr/src/config.rs[474-517]
### What to change
- For private upstream mounts, derive the namespace digest from a canonicalized representation of the *effective credential material*, not just `Authorization`.
- Recommended: hash/HMAC a stable serialization of `UplinkConfig.headers` (sorted by header name; include values) and feed that into `credential_digest(...)` (or introduce a new helper like `headers_digest(...)`).
- Ensure the representation is stable across runs and independent of map iteration order.
- Consider computing/storing the derived namespace at config-load time (to avoid per-request hashing work on hot paths).

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

Description

The updated default pnpr/crates/pnpr/config.yaml still hard-codes the upstream registry to
https://registry.npmjs.org/, so package fetches will target the public registry even when `npm
config get registry` is set to a custom URL. This breaks compatibility with local npm
mirrors/proxies unless additional non-npm configuration is performed.

Code

pnpr/crates/pnpr/config.yaml[R87-90]

+  npmjs:
+    type: upstream
+    url: https://registry.npmjs.org/
+    public: true

Evidence

PR Compliance ID 1 requires using the npm-configured registry URL for downloads; the default mounts
configuration explicitly sets the upstream npmjs mount url to the public npm registry, which
will be used regardless of npm config get registry unless the pnpr config is manually changed.

Respect npm-configured registry URL for package downloads
pnpr/crates/pnpr/config.yaml[87-90]

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 default pnpr configuration hard-codes the upstream registry URL (`https://registry.npmjs.org/`) and does not follow the npm-configured registry, which prevents using local mirrors/proxies via `npm config set registry ...` alone.
## Issue Context
Compliance requires that when npm has a custom registry configured, package metadata/tarball downloads are sourced from that configured registry URL instead of the public default.
## Fix Focus Areas
- pnpr/crates/pnpr/config.yaml[87-90]

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

Description

Storage::for_hosted(org) uses the configured org as a raw filesystem path segment, so an org
like ../../... (or an absolute path) can escape the storage root and redirect
publish/crash-recovery writes outside the intended directory.

Code

pnpr/crates/pnpr/src/storage.rs[R310-311]

+    pub fn for_hosted(&self, org: &str) -> Storage {
+        Storage { hosted: self.hosted.namespaced(org), cached: self.cached.clone() }

Evidence

HostedConfig.org is taken directly from YAML and stored, then used to namespace storage via
for_hosted, which ultimately joins the segment into a path with PathBuf::join, enabling
../absolute-path escapes on filesystem-backed storage; journal recovery also uses for_hosted, so
the same escape applies during crash roll-forward.

pnpr/crates/pnpr/src/config.rs[1604-1632]
pnpr/crates/pnpr/src/storage.rs[303-313]
pnpr/crates/pnpr/src/storage.rs[468-473]
pnpr/crates/pnpr/src/journal.rs[220-230]

Agent prompt

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

## Issue description
Hosted mount `org` namespaces are used as raw path segments (via `PathBuf::join`) when constructing namespaced storage. If `org` contains `..`, path separators, or is absolute, it can escape the storage root and cause writes/reads outside the intended directory.
## Issue Context
- `org` comes from YAML (`mounts: <id>: { type: hosted, org: ... }`) and is stored without validation.
- That value is later used to namespace storage for publish and journal crash recovery.
## Fix Focus Areas
- pnpr/crates/pnpr/src/config.rs[1604-1632]
- pnpr/crates/pnpr/src/storage.rs[303-313]
- pnpr/crates/pnpr/src/storage.rs[468-473]
## Suggested fix
- Add strict validation for hosted `org` at config load (preferred, fail-fast): reject empty is OK, but reject any `org` that:
- is absolute (`Path::is_absolute()`),
- contains `..` components,
- contains path separators (`/` or `\\`) or any non-`Component::Normal` component.
- Alternatively (or additionally), encode `org` into a safe directory name (e.g., percent-encode or base64url) before joining, so arbitrary org ids cannot influence filesystem traversal.
- Ensure the same validated/encoded value is used consistently for fs and S3 namespacing.

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

Description

public: true upstream mounts drop access (becoming anonymously reachable at /~/) but still
allow credential-bearing entries in headers: (including Authorization or API keys), which can
unintentionally expose a private upstream’s contents to unauthenticated clients.

Code

pnpr/crates/pnpr/src/config.rs[R1694-1701]

+    // A public origin is allowlisted and fetched anonymously, so it carries no
+    // access list; its `access:` (if any) is dropped above by the public guard.
+    let access = if file.public { None } else { file.access };
+    let uplink_file = UplinkFile {
+        url: file.url,
+        auth: file.auth,
+        headers: file.headers,
+        maxage: file.maxage,

Evidence

Config explicitly allows credentials in custom uplink headers; resolve_upstream_mount drops
access for public: true while preserving headers, and authorized_uplink treats `access:
None as publicly reachable, making a public` mount with credentialed headers anonymously
accessible.

pnpr/crates/pnpr/src/config.rs[559-562]
pnpr/crates/pnpr/src/config.rs[1674-1709]
pnpr/crates/pnpr/src/server.rs[918-939]

Agent prompt

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

## Issue description
`public: true` is documented/treated as “anonymous, world-readable origin”, but config still permits arbitrary `headers:` for such mounts. Because `authorized_uplink` only enforces access when `access` is present (and `public: true` forces `access: None`), a `public` mount that carries upstream credentials in headers makes a credentialed upstream available to anonymous callers via `/~<mount>/`.
## Issue Context
- `UplinkConfig` explicitly supports credentials in custom headers.
- `resolve_upstream_mount` only rejects `public && auth`, not credential-bearing `headers:`.
## Fix Focus Areas
- pnpr/crates/pnpr/src/config.rs[1674-1709]
- pnpr/crates/pnpr/src/server.rs[918-939]
## Suggested fix
- Enforce the semantic contract: if `public: true`, reject any credential-bearing header configuration.
- At minimum, reject when `headers` contains `Authorization`.
- Preferably, add an explicit `credentialHeaders:` / `sensitiveHeaders:` concept, or reject *all* headers for `public` mounts unless they’re on a conservative allowlist (e.g., `User-Agent`, `Accept`).
- Alternatively, if `public: true` but headers appear credentialed, require `access:` (treat as non-public) and make cache namespacing private.
- Update error messaging to clearly state why the config is rejected (prevents exposing upstream via public mount).

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