When npm announced the end of classic tokens, half of me thought, 'about time,' while the other half immediately pictured old release workflows breaking. Security improvements are annoying in exactly this way: they are doing the right thing, yet they always seem to remind you at release time that a key placed in CI three years ago should never have survived this long.
npm classic tokens were convenient, but they could remain valid for a long time and were often stored in CI. Once exposed, a token could let an attacker publish a modified package as its maintainer.
Stopping the creation of classic tokens pushes publishing toward short-lived tokens, 2FA, and Trusted Publishing. Trusted Publishing verifies a release through the CI platform's identity, removing the need to store a long-lived npm secret.
This can feel distant to developers who only install packages. Yet one compromised maintainer account for a popular dependency can affect a huge number of sites. A little more care in publishing removes a common entry point for the entire ecosystem.
Trusted Publishing stores one fewer secret#
Traditional CI publishing starts by saving an npm token in GitHub Actions secrets. Trusted Publishing instead receives a temporary identity assertion from GitHub Actions, then checks which repository and workflow is publishing. When the run ends, there is no reusable key left behind for months.
It is not a complete solution. A modified workflow or a compromised maintainer account can still cause damage. It does make it harder to steal one token and publish from somewhere else, eliminating a common attack path.