Repository navigation
Harden the release workflow #4
Description
Some hardening for .github/workflows/build-release-changelog.yml. It publishes to npm with NPM_TOKEN, so it's worth tightening:
- Third-party actions are pinned to mutable tags —
mikepenz/release-changelog-builder-action@v4,ncipollo/release-action@v1. Pin to a commit SHA so the tag can't be moved under us. npm ciruns lifecycle scripts in the same job that has the publish token.npm ci --ignore-scriptswould cut that off (build is a plain rollup run and doesn't need them).- Classic
NPM_TOKEN. npm supports OIDC trusted publishing now — no long-lived secret to rotate, and releases get provenance. Needsid-token: write. permissions: contents: writeis job-wide. Only the release step needs it.node-version: '20'is end of life. The build runs fine on 24.
None of this is urgent on its own, but the token makes the job a worthwhile target.
Activity
TimG1804 commentedon Aug 20, 2026
SHA pinning,
--ignore-scripts, Node 24 and thepermissions: {}default are in #11.Left open for the OIDC switch: that needs a trusted publisher configured for the package on npmjs.com, which has to be done by a maintainer there.
--provenanceon top of it also needs therepositoryfield from #9.TimG1804 commentedon Aug 20, 2026
Concrete evidence for the OIDC part: the v0.1.2 release run failed at the publish step.
The package exists and 0.1.1 is on
latest, so this is npm answering an unauthenticated publish with 404 rather than 401.gh secret listshowsNPM_TOKENwas last set on 2024-02-08, and npm has retired classic tokens since.So the token has to be replaced either way — which makes trusted publishing the better thing to set up instead of minting another secret.
ci: harden release workflow
ci: add dependabot for npm and github-actions
ci: harden release workflow
ci: add dependabot for npm and github-actions
TimG1804 commentedon Aug 20, 2026
Correction to my earlier comment: I called the token expired, which is not established. A rejected credential normally surfaces as
E401; theE404seen here fits "authenticated but not authorised to write this package" at least as well. The secret is present and non-empty in the job log, and this same value published 0.1.1.So the case for trusted publishing here is the structural one rather than "the token expired": the package has a single maintainer (
robert-heinig), and a company-sponsored package depending on one persons account and one long-lived secret is what makes a release stall like this. Diagnosis details in #16.TimG1804 commentedon Aug 20, 2026
Cause is confirmed now, see #16: the token was killed by npm's classic token revocation on 2025-12-09, and a revoked token does produce
E404on a scoped publish. My previous comment doubting that was wrong.Does not change the direction here, but sharpens it: a replacement granular token caps at 90 days and loses direct publishing in January 2027, so trusted publishing is the only path worth the setup. Note it needs npm CLI >= 11.5.1, which the Node 24 bump from #12 already provides.
ci: restore workflow hardening and tolerate an existing release
ci: split npm publish and github release into separate jobs (#26)
TimG1804 commentedon Sep 18, 2026
All five points are in place:
mikepenz/release-changelog-builder-action@32e3c96,ncipollo/release-action@339a818npm ci --ignore-scripts— lifecycle scripts no longer run in thepublishing job
NPM_TOKENis gone;0.1.2and0.1.5both carry SLSA provenance, so it is working in practice (see v0.1.2 never published: NPM_TOKEN was revoked in npm's classic token sunset #16)
contents: write— split intopublish-npm(
contents: read+id-token: write) andgithub-release(
contents: write) in ci: split npm publish and github release into separate jobs #26, since Actions has no step-level permissionsThe split is verified by inspection only; the workflow runs on tag push, so
it is first exercised for real at the next release.
Repository-side hardening added alongside this: secret scanning with push
protection, Dependabot security updates, private vulnerability reporting,
SECURITY.md, branch protection onmainwith a requiredbuildcheck,and a ruleset preventing
v*tags from being deleted or force-moved.ci: split npm publish and github release into separate jobs (#26)