NPM to implement staged publishing after turbulent shift off classic tokens

Scope & Design of “Trusted Publishing”

• Multiple comments note that PyPI and Rust implemented Trusted Publishing as an optional CI hardening mechanism, keeping long‑lived API tokens and local publishing, whereas npm tied it to removal/shortening of classic tokens, causing confusion and disruption.
• Some argue npm’s turbulence was self‑inflicted by combining token deprecation with Trusted Publishing rollout and not updating the CLI properly for 2FA publishing.
• There is debate over the term “Trusted Publishing”: some see it as marketing that implies other methods are “untrusted”; designers say it was just a pragmatic name vs “OIDC publishing.”

Centralization, Whitelisting & OIDC

• Strong concerns about centralization and “reverse vendor lock‑in”: only large CI/IdP providers (GitHub, GitLab, etc.) are effectively supported; self‑hosted CI/IdPs are excluded or de‑prioritized.
• Registry operators respond that federation is expensive to maintain, must be carefully vetted, and that API tokens remain first‑class and optional, so no one is forced to use a particular provider.
• Technical discussion explains that Trusted Publishing authenticates CI identities via OIDC, while separate “attestations” (e.g., via Sigstore) address artifact signing and provenance.

Security Model, Scripts & Ecosystem Shape

• Several point out that the core npm risk is not just credentials, but build‑time/postinstall code execution and the sheer number of tiny dependencies that no one can realistically audit.
• Suggestions include: disallow or prompt for postinstall scripts (with per‑project allowlists), forbid network access during builds, and focus on larger, curated “Debian‑style” packages.
• Others counter that distro workflows are not a panacea, citing libxz, and that language‑level managers are needed for portability, version pinning, and richer build behavior.

Impact on Maintainers & Workflow Proposals

• Maintainers complain that unpaid volunteers are being saddled with more operational/security burden; some suggest splitting npm into “use at your own risk” vs commercial/paid tiers.
• CI‑driven projects want a hybrid: Trusted Publishing plus a human‑in‑the‑loop 2FA gate, and staged publishing that allows review before global availability.
• Some fear the aggressive, fast transition will push developers away from Node, while others say friction should instead be added to consumption (e.g., defaulting to pinned versions, avoiding auto‑updates) rather than to publishing.