fix(ci): publish workflow authenticated as nobody (wrong secret name) and asked for provenance it cannot have - #9
Merged
Conversation
…enance it cannot have Two reasons a release-triggered publish would have failed. 1. Wrong secret name. The workflow read `secrets.NPM_TOKEN`. The secret that actually exists on this repo is `NPM_ACCESS_TOKEN` (set 2026-08-21), so NODE_AUTH_TOKEN resolved to an empty string and npm would have published as an anonymous client. I introduced this name in #8 without checking what was configured. 2. `--provenance` cannot work on a first publish. Trusted publishing is configured per package on npmjs.com, which requires the package to already exist — and @certifieddata/verify has never been published, so there is nothing to configure it against. On top of that, a classic automation token combined with --provenance is exactly the combination npm is restricting (https://gh.io/npm-gat-bypass2fa-deprecation); the local CLI now warns about it on every command. Dropped --provenance for 0.1.0 and pointed the token at the right secret. Once 0.1.0 is on the registry, trusted publishing can be enabled for the package and --provenance added back — at which point the token should be deleted rather than kept alongside it. The version-vs-tag guard and the lint/typecheck/test gates are unchanged, so a release still cannot publish a version nobody asked for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Blocks the npm publish.
1. Wrong secret name. The workflow reads
secrets.NPM_TOKEN. The secret that exists on this repo isNPM_ACCESS_TOKEN(set 2026-08-21), soNODE_AUTH_TOKENresolved to an empty string and a release-triggered publish would have authenticated as nobody. I introduced that name in #8 without checking what was configured — my error.2.
--provenancecannot work on a first publish. Trusted publishing is configured per package on npmjs.com and requires the package to already exist.@certifieddata/verifyhas never been published, so there is nothing to configure it against. Separately, a classic automation token plus--provenanceis the exact combination npm is now restricting — the local CLI warns about it on every command (https://gh.io/npm-gat-bypass2fa-deprecation).So
--provenanceis dropped for 0.1.0 and the token points at the right secret. Once 0.1.0 is on the registry, enable trusted publishing for the package, add--provenanceback, and delete the token rather than keeping both.Unchanged: the tag-vs-version guard and the lint/typecheck/test gates, so a release still cannot publish a version nobody asked for.
Context: a direct
npm publishfrom this machine returns403 — Two-factor authentication or granular access token with bypass 2fa enabled is required, so the CI path with a stored token is the way in without an interactive OTP.🤖 Generated with Claude Code