mirror of https://github.com/pnpm/pnpm.git synced 2026-06-28 09:55:39 -04:00

Files

Zoltan Kochan 3b76b8eaed fix(pnpr): access-gate install-accelerator files and remove unauthenticated /v1/files (#12181 )

* fix(pnpr): authorize served packages against pnpr's policy in /v1/install

A content-addressed digest in the install-accelerator store is shared
across packages and says nothing about access, so the store's possession
of a package's bytes is not a capability to receive them. `/v1/install`
served files for any package found in the store, including ones reached
only on the cache-hit / frozen-lockfile path where no access check
happened — letting a caller who knows a private package's digest pull
bytes the registry routes would 401 on.

Check every served package against pnpr's own `packages:` policy before
serving — the same decision `serve_packument` / `serve_tarball` make, in
process, with no network round trip (so a warm shared server keeps its
resolution advantage). `serve_install` resolves the caller's identity
from `Authorization`; `deny_unauthorized_packages` denies the install
(401 anonymous / 403 authenticated-but-outside-the-allowed-set) when any
served package is not readable by the caller.

This authorizes against pnpr's own surface, the authority for everything
the store can hold today (pnpr fetches anonymously, so cached content is
pnpr-hosted or publicly fetchable). When credential forwarding lands,
packages the client resolved from external registries under its own token
carry no pnpr policy and will need per-caller re-verification against the
owning registry (TTL-cached) — noted at the check and tracked in #12184.

The raw `/v1/files` endpoint is still unauthenticated; removing it (it is
superseded by the inline single-response path) is a follow-up (#12184)
that also ports the TS `@pnpm/pnpr.client` + worker off the two-trip path.

---
Written by an agent (Claude Code, claude-opus-4-8).

* fix(pnpr): remove the unauthenticated /v1/files endpoint

`POST /v1/files` served any CAFS file by digest with no authentication
and no package identity, so the access gate on `/v1/install` (which is
per package) couldn't cover it — it had to be removed, not gated. It was
already superseded by the single-response inline path (#12178).

* Server: `/v1/install` always answers with the inline gzipped body
  (lockfile + stats + store-index entries + the missing files' contents);
  the NDJSON two-trip path, the `/v1/files` route, `handle_files`, and the
  `FilesRequest`/`is_valid_sha512_hex` helpers are gone.
* TS client + worker: `@pnpm/pnpr.client` now does the one inline request
  and hands the file frames to `@pnpm/worker`'s `writeCafsFiles`, which
  writes them to the CAFS; the `fetchAndWriteCafsFiles` /v1/files fetcher
  is replaced. Error bodies are decompressed before being surfaced, since
  the server also gzips its JSON error responses (e.g. an access denial).

Verified end to end by `pnpm/test/install/pnpmRegistry.ts` (11 tests:
install / add / remove / workspace through a real pnpr server).

Closes the second half of the install-accelerator access work (#12184);
file-bearing responses are now both inline-only and access-gated.

2026-06-04 09:32:28 +02:00