Summary

pnpr's local OSV database is consulted only by the resolver (/v1/resolve and /v1/verify-lockfile). The npm-registry serving path does not screen by OSV, so a known-vulnerable package version can still be handed to clients that go through the registry rather than the install accelerator.

Current behavior

OsvIndex (in pnpr/crates/pnpr/src/resolver/osv.rs) is read in exactly two places, both resolver handlers:

• serve_resolve — used as a PackageVersionGuard during resolution and to report violations
• serve_verify_lockfile — used to verify an input lockfile

The proxy/serving path in pnpr/crates/pnpr/src/upstream.rs (fetch_packument, fetch_tarball_response, abbreviate_packument) has no OSV/version-filtering logic. Because cache hits and proxied responses flow through the same packument/tarball handlers, neither proxied nor cache-served responses are screened.

Expected behavior

OSV screening is a cross-cutting policy that should apply to every surface that hands out package content, not just resolution. When an OSV database is configured, the registry should:

1. Packument serving (proxy and cache): omit (or otherwise mark) known-vulnerable versions from served packuments, so any client — even one not using the accelerator — never resolves to a vulnerable version.
2. Tarball serving (proxy and cache): refuse to serve a tarball for a known-vulnerable version.

This should hold regardless of whether the bytes come from an upstream proxy fetch or the local cache.

Notes

• The OSV setting stays top-level (not nested under the new registry / resolver feature blocks) precisely because it is cross-cutting — it governs whichever surfaces are mounted. See the feature-toggle work that introduced registry.enabled / resolver.enabled.
• Design questions to settle when implementing: filter-out vs. annotate vulnerable versions in packuments; whether screening is gated by the existing osv.enabled; and how it interacts with dist-tags that point at a screened version.

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