npm registry keeps removed-version timestamps but drops the reason (Sept 2025 campaign as evidence)
npm keeps timestamps for removed package versions but drops the removal reason, hindering supply-chain response.
An oss-security post reports a retention asymmetry in npm's public package documents that matters for supply-chain incident response. When a version is removed, it disappears from the versions map and direct fetches return 404, but its key usually remains in the time map of publish timestamps. The registry therefore preserves evidence that a version existed while dropping the reason for removal. The author points to a September 2025 campaign as evidence.
- Removed npm versions leave the versions map and direct fetches return 404.
- Their publish timestamps usually remain in the package time map.
- The registry keeps that a version existed but drops why it was removed.
- The author cites a September 2025 campaign as evidence for incident response.
Posted by ezraax on Sep 23 Hi, Sharing a registry-metadata observation that matters for supply-chain incident response. I audited npm's public package documents and found a retention asymmetry. Each package document has a `time` map (per-version publish stamps) and a `versions` map (the manifests). When a version is removed it disappears from `versions` and direct fetch 404s, but its numeric key usually stays in `time`. So the registry keeps the fact that a...
This source does not provide full text. Read it at seclists.org.