Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
perf: cache pnpm's lockfile verification results #287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Uh oh!
There was an error while loading. Please reload this page.
perf: cache pnpm's lockfile verification results #287
Changes from all commits
c0a6b0ff141ddd544072db543421e6cb65a34f0a19987541bFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
Large diffs are not rendered by default.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 Performance & Scalability | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
Repository: pnpm/action-setup
Length of output: 4902
🏁 Script executed:
Repository: pnpm/action-setup
Length of output: 11152
🏁 Script executed:
Repository: pnpm/action-setup
Length of output: 2664
🏁 Script executed:
Repository: pnpm/action-setup
Length of output: 2210
🌐 Web query:
pnpm v11 lockfile verification cache minimumReleaseAge trustPolicy lockfile-verified.jsonl policy changes💡 Result:
In pnpm v11, lockfile verification was significantly hardened to prevent supply-chain attacks, primarily by ensuring that existing lockfile entries are re-validated against security policies even when they were already present in the lockfile [1][2][3]. Previously, pnpm might skip security checks for dependencies already resolved in the lockfile, which created a vulnerability where malicious or immature packages could persist undetected [3]. Key components and changes in pnpm v11 regarding lockfile verification: 1. Mandatory Lockfile Re-validation: pnpm v11 introduced a post-load, pre-fetch gate that re-applies policies like minimumReleaseAge and trustPolicy ('no-downgrade') to every dependency entry in the lockfile [4][1][2]. If a locked version violates these policies, the install aborts (e.g., ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION) [1]. 2. trustPolicy and minimumReleaseAge: - trustPolicy: 'no-downgrade' ensures that a lockfile entry does not use a version with weaker security evidence (like missing provenance) than an earlier published version [5]. - minimumReleaseAge: Enforces a time-based cutoff for packages to prevent installing very recent (potentially malicious) releases [1]. 3. trustLockfile Setting: Introduced in v11.3, this setting allows users to explicitly opt out of the re-validation pass for trusted environments, such as closed-source projects where every commit is authored by a trusted team member [4][6][7]. When set to true in pnpm-workspace.yaml (or via --trust-lockfile), pnpm skips the verification of existing lockfile entries to improve performance and avoid potential memory bottlenecks [6][7]. 4. Performance and Memory Optimizations: Early iterations of the v11 re-validation pass caused significant memory usage and performance regressions on large workspaces [8][7]. Subsequent updates (v11.3 and later) optimized this by: - Storing only essential metadata fields (time, trustedPublisher, attestations) in the cache rather than full packuments [4][6]. - Enabling metadata cache reuse for the verification pass, resolving issues where re-validation would incorrectly attempt to fetch full metadata for every entry [8]. - Running lockfile verification concurrently with fetching and linking instead of blocking the entire installation process [9]. 5. Verification Security: Regardless of policies, pnpm v11 also enforces an always-on integrity check for tarballs and rejects malformed or malicious lockfile aliases (e.g., those attempting path traversal) before any filesystem operations occur [10][9]. Regarding "lockfile-verified.jsonl," this file is not a standard pnpm-maintained configuration file; based on current documentation, it does not exist as a formal part of the pnpm v11 specification. Verification results and policy enforcements are handled internally by pnpm's resolution and installation engines [1][5].
Citations:
minimumReleaseAgenot enforced when dependency already exists in lockfile pnpm#10438🌐 Web query:
site:github.com/pnpm/pnpm "lockfile-verified.jsonl"💡 Result:
lockfile-verified.jsonl is a cache file used by the pnpm package manager (and its associated Rust-based implementation, pacquet) to store and memoize the results of lockfile verification checks [1][2][3]. Its primary purpose is to enable a fast-path performance optimization during the installation process. When pnpm performs lockfile verification—such as checking policies like minimumReleaseAge—it caches the outcome in this file [2][3]. On subsequent runs, if the lockfile remains unchanged, pnpm can use this cached record to skip redundant verification steps [4][5][2]. Key technical aspects include: - Format: It uses the JSON Lines (JSONL) format [1][3]. - Optimization logic: It employs a "stat shortcut" to quickly identify unchanged lockfiles by comparing metadata such as file size, modification time (mtime), and inode [1][3]. If the metadata matches, it avoids expensive re-hashing of the lockfile [1]. - Reliability: If metadata differs (for example, in CI environments where file timestamps may be reset), it falls back to a content-based hash (sha256) to verify if the lockfile is effectively the same [1][3]. - Location: The file is stored within pnpm's on-disk cache directory [4][5]. - Maintenance: It includes a compaction mechanism that dedupes entries by (path, hash) and prunes old entries to maintain a reasonable file size [2]. By memoizing these verification verdicts, pnpm significantly improves performance for repeated installs in scenarios where lockfile integrity policies are enforced [6][3].
Citations:
🌐 Web query:
site:github.com/pnpm/pnpm "trustLockfile" "minimumReleaseAge" cache verification💡 Result:
In pnpm v11, the
trustLockfilesetting and theminimumReleaseAgepolicy are part of a supply-chain verification system designed to validate lockfile entries before any packages are fetched [1][2][3]. trustLockfile ThetrustLockfileconfiguration option (defaultfalse) allows you to opt out of the automatic lockfile verification pass [4][3]. When set totrue, pnpm skips the re-application ofminimumReleaseAgeandtrustPolicy('no-downgrade') to the entries in the loaded lockfile [4][3]. This is intended for secure, closed-source environments where every commit is made by a trusted author and the lockfile is considered inherently trustworthy [4][3]. Lockfile Verification and Cache WhentrustLockfileisfalse(the default), pnpm runs a verification gate on every install [4][2]. This process ensures that lockfile entries still adhere to your configured security policies, even if the lockfile was generated by a different machine or cached by CI [2]. To optimize this process, pnpm uses a verification cache: - Cache Mechanism: Results of the lockfile verification are stored in a local file (often tracked aslockfile-verified.jsonl) [5][6][7]. - Cache Keying: The cache is keyed by the lockfile's content hash and the active policy snapshot [6][7]. If both remain unchanged, pnpm can skip the per-package registry metadata round-trips required for verification [1][6]. - Cache Visibility: Recent updates have made these "cached" verdicts more visible, allowing developers to see when the verification gate has short-circuited due to a previous pass [5]. minimumReleaseAge TheminimumReleaseAgepolicy rejects package versions that are younger than a specified time duration [2]. Because this check is part of the verification gate, it is re-applied during every install unlesstrustLockfileis active [1][2]. This ensures that even if a version was "old enough" when originally resolved, an install will still fail if the registry metadata or policy configuration dictates that the version no longer meets the maturity requirements [2]. Note that this verification is "fail-closed"—if the registry is unreachable or fails to provide the necessary metadata, the install will be rejected [1]. For high-performance or offline environments, pnpm also supports offloading this verification to a remote server (such aspnpr), which maintains its own server-side cache for these verdicts [6][7].Citations:
🏁 Script executed:
Repository: pnpm/action-setup
Length of output: 679
🌐 Web query:
https://github.com/pnpm/pnpm/blob/a751c7f2/pacquet/crates/lockfile-verification/src/cache.rs policy hash lockfile-verified.jsonl💡 Result:
The file lockfile-verified.jsonl serves as a persistent, on-disk cache for lockfile verification results in pnpm's Pacquet implementation [1][2]. Its primary purpose is to avoid redundant, expensive registry lookups and lockfile hashing on repeated installs when the lockfile and verification policies remain unchanged [2][3][4]. Key technical aspects include: 1. Functionality: It acts as a memoization layer for the lockfile verification process (which enforces policies like minimumReleaseAge or trustPolicy) [2][3]. When a user runs an install, the system checks this cache first. If a valid, compatible record exists, the verification gate is bypassed [5][6][4]. 2. Cache Logic: The system uses a "stat shortcut" to quickly identify if the lockfile has changed [3]. It compares current file metadata (size, mtime, inode) against the cached record [2][3]. If the metadata matches, the system trusts the previous verification result [3]. If it differs, it falls back to computing a hash of the lockfile to confirm if the content is still valid under the currently active policies [2][3]. 3. Policy Hash/Snapshot: To ensure correctness, the cache record includes a representation of the policies in effect at the time of verification [1][5]. This prevents "downgrade" issues where a user might tighten their security policies (e.g., increasing a minimum release age) between two installations; if the policies are different, the cache entry is invalidated, and re-verification occurs [5][3][4]. 4. Compatibility: This file is designed to mirror the behavior of the upstream TypeScript implementation in pnpm, ensuring that caches populated by one version or implementation can be read by others [1]. 5. Maintenance: The cache includes built-in compaction logic to manage its size, typically triggered when it reaches a certain number of entries or size limit (e.g., 1000 entries or ~1.5MB) [2]. This mechanism effectively enables "fast-path" installs that complete in milliseconds when the environment is warm and the project state is unchanged [5][4].
Citations:
verify_lockfile_resolutions, defeating the fast path on cache wipes pnpm#11940🌐 Web query:
https://github.com/pnpm/pnpm/blob/a751c7f2/pacquet/crates/lockfile-verification/src/verify_lockfile_resolutions.rs policy cache key💡 Result:
In the pnpm codebase, specifically within the pacquet project's lockfile verification logic, the policy cache key is derived from a combination of the lockfile's content (often hashed) and the active security or supply-chain policy snapshots [1][2][3]. The system uses a cache to short-circuit the lockfile verification process, which ensures that dependencies meet defined security and integrity policies [1][4]. The caching mechanism functions as follows: 1. Cache Identity: Verification is memoized based on an identity that includes the lockfile's state (typically its hash) and the merged policy snapshot [2][3]. Every active ResolutionVerifier contributes its policy to this merged map [2]. 2. Cache Lookup: Before running full verification, the system performs a lookup using this identity [2][4]. If a previous, successful verification run matches the current lockfile and satisfies a policy at least as strict as the current one, the system can skip the full verification pass [2][4]. 3. Implementation: In the Rust implementation (
pacquet), this logic is handled within thelockfile-verificationcrate [1][5]. TheCacheRecordstruct, which stores these results, explicitly includes apolicyfield (a JSON map of the policy snapshot) alongside the lockfile's metadata (hash, path, size, etc.) [2]. This approach ensures that if a lockfile remains unchanged and the required security policies have not become more stringent, the expensive verification gate can be safely bypassed [2][4]. If either thecache_dirorlockfile_pathis omitted, the cache is disabled, forcing a full re-hash and re-verification of the gate [1].Citations:
🏁 Script executed:
Repository: pnpm/action-setup
Length of output: 34144
🏁 Script executed:
Repository: pnpm/action-setup
Length of output: 8457
Include the effective verification-policy configuration in the cache key.
pnpm stores the policy snapshot in
lockfile-verified.jsonland re-verifies when the current policy cannot trust that snapshot. This prevents an incorrect verdict, but the action does not save the reverified file after an exact cache restore. A stricter policy can therefore trigger registry verification on every subsequent run.Add a stable fingerprint of the effective policy configuration to the key, and update
action.ymlandREADME.md.🤖 Prompt for AI Agents
Uh oh!
There was an error while loading. Please reload this page.