Release tags need separate keys

npm just closed one of those gaps that only looks small if you have never maintained a package.

Trusted publishing already let maintainers publish npm packages from CI with short-lived OIDC credentials instead of long-lived npm tokens. The missing piece was npm dist-tag. You could remove the token from the publish step, then keep a token around just to move latest, next, or beta after the release.

That is the kind of security improvement that still leaves a spare key under the mat.

GitHub's September 30 changelog says trusted publishing configurations can now opt in to dist-tag management. The permission defaults off. It is independent from direct publishing. A staging-only configuration can manage tags without also getting direct npm publish rights. npm's docs add the operational details: dist-tag OIDC support requires npm CLI 11.21.0 or 12.2.0 or later, and public tag reads remain unauthenticated.

Sources: GitHub changelog on opt-in dist-tag permissions, npm trusted publishing docs, GitHub OpenID Connect documentation, and npm token security changes.

Promotion is a different verb

Publishing a package and promoting a version are related, but they are not the same action.

npm publish creates or uploads a version. npm dist-tag add package@version latest changes what most installs resolve to. That second action can be more dangerous than it sounds. A bad latest move can point everyone at the wrong build even if the package versions themselves are fine.

So the permission model should treat promotion as its own verb.

That is the useful part of this npm change. It does not say, "This workflow is trusted, so let it do release things." It says, "This workflow may publish, stage, and/or move tags, depending on exactly what the maintainer selected."

Developer tools should do more of that.

The rollback path needs design too

Release workflows often obsess over the happy path: tag, build, test, publish. The awkward part comes later, when you need to move latest back, promote a canary, or point next at a release candidate without opening a broad token again.

That is where long-lived tokens sneak back in.

A team does the responsible thing and moves publishing to OIDC. Then one release script fails because npm dist-tag still needs classic authentication. The practical fix is obvious: add a token. Maybe a granular token. Maybe stored in a secret. Maybe rotated later, when everyone is less busy.

Nobody plans the exception. The exception just becomes part of the system.

Opt-in dist-tag permission gives maintainers a cleaner rollback surface. You can create a workflow whose job is tag movement, not full publication. You can keep the blast radius smaller. You can review that file differently from the release file.

That is not glamorous security. It is release hygiene.

UI copy is part of the boundary

The npm docs call the setting "Allowed actions" and split publishing, staging, and dist-tags. That naming matters.

A vague checkbox like "trusted workflow" would be worse. It would make the maintainer infer what trust means. The better interface names the action directly: can this workflow publish? Can it stage? Can it manage dist-tags?

The defaults matter too. GitHub says the dist-tag permission is off for new and existing configurations, so no existing workflow silently gains a new capability. That is the right instinct. When a permission adds a new verb, the tool should make the maintainer choose it on purpose.

I would still want an audit receipt in the package settings: which workflow moved which tag, from which version to which version, using which trusted publisher configuration. npm may already have internal logs, but the maintainer interface should make that trail easy to inspect during a release incident.

The pattern to steal

The pattern is not "use npm trusted publishing," although you probably should if you maintain a package and your CI provider is supported.

The pattern is smaller:

Separate creation from promotion.
Separate happy-path release from rollback.
Separate broad trust from named actions.

That applies to more than npm. It applies to container tags, GitHub Releases, feature flags, Postiz publishing queues, and any automation where moving a pointer changes what users receive.

A release system should make the final pointer move feel heavier than another shell command. Not slower. Heavier. The person reading the workflow should be able to see exactly who is allowed to move the line between "available" and "default."

npm's dist-tag permission is a small checkbox. Good release design is often exactly that: one small checkbox that removes the last excuse for keeping a dangerous token alive.