




























Socket proactively blocks malicious open source packages in your code.
pnpm 11.5 now treats npm staged publishing approvals as strong trust evidence, fixing a false-positive downgrade warning that could appear when packages used npm’s newer 2FA-backed release flow.
The change lands as npm continues tightening package publishing controls after a series of credential theft and token abuse incidents. In the Mini Shai-Hulud campaign, attackers used stolen npm tokens to publish malicious package versions, prompting npm to invalidate granular access tokens and accelerate changes that reduce reliance on long-lived publishing credentials. Staged publishing places a package version in a staging state before it becomes installable, requiring a maintainer with publish access to approve the release through a 2FA challenge.
When a package version’s registry metadata includes an approver field, pnpm now ranks it above trusted publishing and provenance attestations. Staged publish approval is treated as pnpm’s strongest trust signal, rather than being mistaken for a fallback to less-secure traditional token-based publishing.
The fix follows a report from Kevin Deng, who found that pnpm’s trustPolicy: no-downgrade setting could incorrectly treat staged publishing approval as a downgrade from trusted publishing.

The no-downgrade policy is meant to warn when a package appears to move from a stronger publishing mechanism to a weaker one. That is useful for detecting suspicious changes, such as a package that previously used trusted publishing but later appears to fall back to classic account or token-based publishing.
Staged publishing complicated that logic. The issue noted that pnpm appeared to infer whether a package used trusted publishing by inspecting the _npmUser field. But when staged publishing is enabled, _npmUser may point to the npm user who approved the staged publish. That made a package version look like a false downgrade, even when the release still came through a trusted publishing flow.
pnpm 11.5 resolves this by recognizing staged publishing approval as its own trust signal. If registry metadata includes an approver, pnpm treats the release as having the strongest trust evidence rather than classifying it as a downgrade.
The related npm community discussion points to a larger metadata problem for package managers and security tools.
In that discussion, Deng asked npm to expose explicit registry metadata showing how a package version was published, including whether it used trusted publishing or staged publishing. The issue is that tools should not have to infer publishing security properties from fields like _npmUser, especially as npm adds more publishing modes.

npm now supports several release paths with different security properties:
Those mechanisms can also be combined. npm has said staged publishing works with trusted publishing, allowing CI to push a version into staging while a human maintainer separately approves it before release. For package managers and scanners, this adds a new responsibility to accurately interpret the security properties of a version based on the metadata exposed by the registry.
pnpm’s fix is a practical example of how package managers are adapting to npm’s newer security model. As registry publishing workflows become more granular, install tools need more precise metadata to avoid both missed warnings and noisy false positives.
pnpm 11.5 includes several other supply chain-adjacent fixes:
minimumReleaseAgeExclude handling, so excluded packages are not pinned to stale versions in npm resolution fast pathsintegrity field for remote HTTPS tarball dependencies when unrelated packages are installed afterwardpnpm dist-tag add and pnpm dist-tag rm against npmjs.orgFor staged publishes, the update is mainly about avoiding misclassification. pnpm 11.5 keeps staged publishes from being misread as a downgrade from trusted publishing to classic user or token-based publishing, which should reduce noisy no-downgrade alerts for projects using npm’s newer release controls.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。