8e17c3d366
Pure directory move plus path fixups: the Rust port ships as pnpm v12, so the source tree now lives at pnpm/ (alongside pnpm11/, the frozen TypeScript line). No identifiers change in this pass — crate names (pacquet-*), the pacquet bin, PACQUET_VERSION, the @pacquet/* npm package names v11's runPacquet spawns, the .pacquet virtual-store dir, the benchmark harness's clone dir, and the pacquet-*.yml workflow filenames (npm trusted publishing is bound to them) all stay for a follow-up. Also removes the root /pnpm/ .gitignore entry (build detritus in the pre-pnpm11 package location): pnpm/ is real source now and must not be ignored. Developers with a stale generated pnpm/ dir should delete it before checking out this change.
2.8 KiB
Security Policy
Supported Versions
| Version | Supported |
|---|---|
| 11.x | ✅ till 2027 April 30 |
| 10.x | ✅ till 2027 April 30 |
| <= 9.x | ❌ |
Reporting a Vulnerability
Submit your findings here: https://github.com/pnpm/pnpm/security/advisories
We do not operate a bounty program.
pacquet and pnpr
The Rust port (pnpm/) and the resolver server (pnpr/) are not
production ready and are under active development. Do not report security
issues in them through the security advisory process — open a
regular issue in this repository instead.
Threat Model and Scope
pnpm's security boundary is filesystem permissions. We assume that the store
directory, the project directory, node_modules, the lockfile, and pnpm's
configuration files are only writable by parties the user already trusts. A
report that assumes an attacker who already has write access to any of these
locations is out of scope — at that point the trust boundary has already
been crossed and the attacker can achieve code execution regardless of pnpm's
behavior.
In particular:
-
The content-addressable store is not a security boundary against a write-capable local adversary. The integrity hashes recorded for each file live inside the store itself (e.g.
<storeDir>/v3/files/index.db), in the same trust domain as the files they describe. Anyone who can modify a file in the store can also modify its recorded hash. Integrity verification therefore exists to detect accidental corruption (interrupted writes, bit-rot, partially fetched tarballs), not to defend against tampering by someone who can already write to the store. Optimizations such as themtimefast path do not weaken this guarantee, because the guarantee was never tampering resistance. -
The store must not be shared among mutually-untrusting users. A store writable by an untrusted party is equivalent to letting that party write arbitrary code into your
node_modules. If you share a store across users or CI jobs, restrict write access to trusted identities via filesystem permissions.
The following are examples of reports we consider out of scope:
- Tampering with store, lockfile,
node_modules, or config files that the attacker can already write to. - Bypassing store integrity checks given pre-existing write access to the store.
- Attacks that require the user to run pnpm with a maliciously crafted local project or environment that they did not obtain from a trusted source.
If you believe a report falls outside these assumptions — for example, a way to bypass a trust boundary that pnpm does enforce — please include the exact privilege the attacker starts with and how pnpm escalates it.