A Difference Without a Distinction: A Measurement Study of Release Trust Evidence in Package Registries

Abstract

A stolen npm token or account lets an attacker publish a malicious version of a popular package. Such uploads skip the project's CI workflow and can lack its provenance, so since November 2025 an opt-in pnpm policy refuses any release with weaker evidence than an earlier one. Maintainers also publish backports by hand; how often the policy blocks them and which attacks it flags is unknown. We test the policy on the latest versions of 1,997 popular and recently updated npm packages, replay its variants and identity pins on reconstructed stolen-credential incidents, and analyze an npm malware advisory census. We also compare publication evidence across five package registries: npm, PyPI, Maven Central, crates.io, and RubyGems. With pnpm 10.29.3, 1.6% of popular and 7.6% of recently updated installs are blocked, mostly by backports, and one security fix backported by hand, semver 6.3.1, causes 14 of the 16 popular failures. The policy can flag an attack only if an earlier release of the same package carried stronger evidence. In the census, 17.5% of attacked packages had earlier evidence; two campaigns supply about half of these. Attackers with the observed access could have passed 15 of the 17 flagged releases by adding evidence. Pins on the full signing identity alert on 75.8% of packages with at least two keyless-signed releases, largely because certificates name the Git branch or tag. No variant tells a recent backport and an attack apart: comparing per line or declaring manual lines at the registry admits both, and an age cutoff exempts only old releases.

arXiv comment8 pages + refs + appendix