[HN Gopher] NPM to implement staged publishing after turbulent s...
___________________________________________________________________
NPM to implement staged publishing after turbulent shift off
classic tokens
Author : feross
Score : 105 points
Date : 2026-01-07 18:31 UTC (4 hours ago)
(HTM) web link (socket.dev)
(TXT) w3m dump (socket.dev)
| woodruffw wrote:
| > In its current form, however, trusted publishing applies to a
| limited set of use cases. Support is restricted to a small number
| of CI providers, it cannot be used for the first publish of a new
| package, and it does not yet offer enforcement mechanisms such as
| mandatory 2FA at publish time. Those constraints have led
| maintainer groups to caution against treating trusted publishing
| as a universal upgrade, particularly for high-impact or critical
| packages.
|
| This isn't strictly accurate: when we designed Trusted Publishing
| for PyPI, we designed it to be generic across OIDC IdPs
| (typically CI providers), and explicitly included an
| accommodation for creating new projects via Trusted Publishing
| (we called it "pending" publishers[1]). The latter is something
| that not all subsequent adopters of the Trusted Publishing
| technique have adopted, which is IMO both unfortunate and
| understandable (since it's a complication over the data
| model/assumptions around package existence).
|
| I think a lot of the pains here are self-inflicted on GitHub's
| part here: deciding to remove normal API credentials entirely
| strikes me as extremely aggressive, and is completely unrelated
| to implementing Trusted Publishing. Combining the two together in
| the same campaign has made things unnecessarily confusing for
| users and integrators, it seems.
|
| [1]: https://docs.pypi.org/trusted-publishers/creating-a-
| project-...
| epage wrote:
| As I'm not familiar with the npm ecosystem so maybe I'm
| misunderstanding this but it sounds like they removed support
| for local publishes (via a token) in favor of CI publishing
| using Trusted Publishing.
|
| If that is correct, I thought this was discussed when Trusted
| Publishing was proposed for Rust that it was not meant to
| replace local publishing, only harden CI publishing.
| woodruffw wrote:
| > If that is correct, I thought this was discussed when
| Trusted Publishing was proposed for Rust that it was not
| meant to replace local publishing, only harden CI publishing.
|
| Yes, that's right, and that's how it was implemented for both
| Rust and Python. NPM seems to have decided to do their own
| thing here.
|
| (More precisely, I think NPM still allows local publishing
| with an API token, they just won't grant long-lived ones
| anymore.)
| the_mitsuhiko wrote:
| I think the path to dependency on closed publishers was
| opened wide with the introduction of both attestations and
| trusted publishing. People now have assigned extra
| qualities to such releases and it pushes the ecosystem
| towards more dependency on closed CI systems such as github
| and gitlab.
|
| It was a good intention, but the ramifications of it I
| don't think are great.
| woodruffw wrote:
| > People now have assigned extra qualities to such
| releases and it pushes the ecosystem towards more
| dependency on closed CI systems such as github and
| gitlab.
|
| I think this is unfortunately true, but it's also a tale
| as old as time. I think PyPI did a good job of
| documenting why you _shouldn 't_ treat attestations as
| evidence of security modulo independent trust in an
| identity[1], but the temptation to verify a signature and
| call it a day is great for a lot of people.
|
| Still, I don't know what a better solution is -- I think
| there's general agreement that packaging ecosystems
| should have _some_ cryptographically sound way for
| responsible parties to correlate identities to their
| packages, and that previous techniques don 't have a
| great track record.
|
| (Something that's noteworthy is that PyPI's
| implementation of attestations uses CI/CD identities
| because it's easy, but that's not a fundamental
| limitation: it could also allow email identities with a
| bit more work. I'd love to see more experimentation in
| that direction, given that it lifts the dependency on
| CI/CD platforms.)
|
| [1]: https://docs.pypi.org/attestations/security-model/
| spankalee wrote:
| I maintain some very highly used npm package and this situation
| just has me on edge. In our last release of dozens of packages, I
| was manually reading though our package-lock and package.json
| changes and reviewing every dependency change. Luckily our core
| libraries have no external dependencies, but our tooling has a
| ton.
|
| We were left with a tough choice of moving to Trusted Publishers
| or allowing a few team members to publish locally with 2FA. We
| decided on Trusted Publishers because we've had an automated
| process with review steps for years, but we understand there's
| still a chance of a hack, so we're just extremely cautious with
| any PRs right now. Turning on Trusted Publishers was a huge pain
| with so many package.
|
| The real thing we want for publishing is for us is to be able to
| continue to use our CI-based publishing setup, with Trusted
| Publishers, but with a human-in-the-loop 2FA step.
|
| But that's only part of a complete solution. HITL is only
| guaranteed to slow down malicious code propagating. It doesn't
| actually protect our project against compromised dependencies,
| and doesn't really help prevent us from spreading it. All of that
| is still a manual responsibility of the humans. We need tools to
| lock down and analyze our dependencies better, and tools to
| analyze our our packages before publishing. I also want better
| tools for analyzing and sandboxing 3rd party PRs before running
| CI. Right now we have HITL there, but we have to manually
| investigate each PR before running tests.
| m4rtink wrote:
| Can we finally decare this (and other incomplete language
| specific package namanegers) to be a failed experiment and go
| back to robust and secure distro based package management
| workflow, with maintainers separate from upstream developpers ?
| ashishb wrote:
| I run them inside a sandbox.
|
| The npm community is too big that one can never discard it for
| frontend development.
| arccy wrote:
| where do you get all these trusted people to review your
| dependencies from?
|
| it can't be anyone, because you're essentially delegating
| trust.
|
| no way there's enough trustworthy volunteers (and how do you
| vet them all?)
|
| and who's going to pay them if they're not volunteers?
| Macha wrote:
| The robust and secure distro based package management workflow
| that shipped the libxz backdoor to everyone, and broke openssh
| key generation, and most of the functionality of keepassxc?
| echelon wrote:
| Never in a million years.
|
| Rust's Cargo is sublime. System apt / yum / pacman / brew could
| never replace it.
|
| Cargo handles so much responsibility outside of system packages
| that they couldn't even come close to replicating the utility.
|
| Checking language versions, editions, compiling macros and
| sources, cross-compiling for foreign architectures, linking,
| handling upgrades, transient dependency versioning, handling
| conflicts, feature gating, optional compilation, custom linting
| and strictness, installing sidecars and cli utilities, etc.
| etc.
|
| Once it's hermetic and namespaced, cargo will be better than
| apt / yum / etc. They're not really performing the same tasks,
| but cargo is just so damned good at such important things that
| it's hard to imagine a better tool.
| no_wizard wrote:
| Its a false belief that distro based package management
| workflows are, or ever were, more secure. Its the same problem,
| maybe one step removed. Look at all the exploits with things
| like libxz
|
| There was also the python 2.7 problem for a long time, thanks
| to this model, it couldn't be updated quickly and developers,
| including the OS developers, became dependent on it being there
| by default, and built things around it.
|
| Then when it EOL'd, it left alot of people exposed to
| vulnerabilities and was quite the mess to update.
| rtpg wrote:
| When distros figure out how I can test my software with a dep
| at version A and the same dep at version B in a straightforward
| way, then we can talk.
|
| NPM forcing a human to click a button on release would have
| solved a lot of this stuff. So would have many other
| mitigations.
| lloydatkinson wrote:
| Just to be clear, "trusted publishing" means a type of reverse
| vendor lock in? Only some CI systems are allowed to be used for
| it.
| LtWorf wrote:
| Yes. You cannot set up your own.
| herpdyderp wrote:
| The shift wouldn't have been so turbulent if npm had simply
| updated their CLI in tandem. I still can't use 2FA to publish
| because their CLI simply cannot handle it.
___________________________________________________________________
(page generated 2026-01-07 23:00 UTC)