ci: migrate npm publish to OIDC trusted publishing

[JohnMcLear]

Summary

• Replace stored `NPM_TOKEN` auth with npm OIDC trusted publishing — no expiring credential, no token rotation, no possibility of a stale secret blocking releases
• Add `--provenance` so the npm package page shows the signed-by-GitHub attestation
• Bump publish job's pnpm pin from 10 → 11 (matches test job; trusted publishing needs pnpm ≥ 10.4)
• Remove the per-publish `npm access grant` step — the grant is idempotent and was already applied at initial publish; it doesn't need to run on every release, and an OIDC credential isn't authorised for it anyway

Why now

The post-merge publish for #981 failed E404 in run 26279691349 — "The requested resource 'ueberdb2@6.1.1' could not be found or you do not have permission to access it" — the classic shape of a stored token that's expired or had its scope changed. `ep_hljs` hit the same pattern four days ago. Migrating off the stored token is the permanent fix; rotating the token would just defer the problem to the next rotation cycle.

This also unblocks ether/etherpad#7831, whose CI is stuck waiting for ueberdb2 6.1.1 to actually land on npm.

One-time setup required after merge

On https://www.npmjs.com/package/ueberdb2/access:

1. `Trusted Publishers → Add`
2. Provider: `GitHub Actions`
3. Organization: `ether`
4. Repository: `ueberDB`
5. Workflow filename: `npmpublish.yml`
6. Environment: leave blank

Same recipe documented at the top of the `publish-npm` job in the workflow.

Test plan

• Workflow YAML lints (`actionlint` clean; same shape as existing ether/ OIDC publishers)
• After the one-time npm UI setup, the next push to main will publish `ueberdb2@6.1.2` via OIDC; `npm view ueberdb2 dist-tags.latest` should update
• Once published, fix: page sessionstorage cleanup to avoid OOM (#7830) etherpad#7831 lockfile regenerates against `^6.1.0` and CI goes green

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Migrate npm publish to OIDC trusted publishing

✨ Enhancement

Walkthroughs

Description

• Replace stored NPM_TOKEN with OIDC trusted publishing
• Add provenance attestation to published packages
• Bump pnpm version from 10 to 11
• Remove per-publish npm access grant step

Diagram

flowchart LR
  A["Stored NPM_TOKEN<br/>expires/rotates"] -->|Remove| B["OIDC Trusted<br/>Publishing"]
  B -->|GitHub id-token| C["Short-lived<br/>credential"]
  C -->|pnpm publish| D["npm registry"]
  D -->|--provenance| E["Signed attestation<br/>on package page"]

Loading

File Changes

1. .github/workflows/npmpublish.yml ✨ Enhancement +25/-16

Migrate to OIDC trusted publishing with provenance

• Add permissions block with contents: write and id-token: write for OIDC authentication
• Add registry-url: 'https://registry.npmjs.org' to setup-node action
• Bump pnpm version from 10 to 11
• Remove "Set publishing config" step that consumed NPM_TOKEN secret
• Remove "Add package to etherpad organization" step (idempotent access grant)
• Update pnpm publish command with --no-git-checks and --provenance flags
• Add comprehensive comments explaining OIDC setup and one-time npm configuration

.github/workflows/npmpublish.yml

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

1. OIDC active during install 🐞 Bug ⛨ Security

Description

The publish-npm job enables id-token: write for the entire job, so any code executed during
pnpm install/pnpm run build can request a GitHub OIDC token and exchange it for an npm publish
credential. This increases the impact of a compromised dependency or build-time script because it
could publish to npm and also push commits/tags via contents: write.

Code

.github/workflows/npmpublish.yml[R68-70]

Evidence

The job-level permissions enable OIDC before any steps run, and the same job later executes
install/build commands (which can run arbitrary scripts from dependencies) before publishing.

.github/workflows/npmpublish.yml[59-70]
.github/workflows/npmpublish.yml[100-137]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow grants `id-token: write` (OIDC) and `contents: write` to the entire `publish-npm` job, while also running dependency installation and build steps. Any code executed in those steps can request an OIDC token and obtain publish credentials.

## Issue Context
`publish-npm` runs `pnpm install` and `pnpm run build` before `pnpm publish`, but OIDC permission is already enabled at the job level.

## Fix Focus Areas
- .github/workflows/npmpublish.yml[54-137]

### Implementation direction
- Split into two jobs:
 - **build** job: no `id-token: write` and no `contents: write`; runs `pnpm install` + `pnpm run build`; uploads the build output (or a packed tarball via `pnpm pack`).
 - **publish** job: depends on build job; minimal steps (download artifact + publish) and the only place where `id-token: write` is granted.
- If a separate job is not feasible, reduce executable surface where possible (e.g., avoid running install-time scripts unless strictly required) while keeping OIDC-enabled steps as late as possible.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unpinned actions in publish 🐞 Bug ⛨ Security

Description

The publish-npm job runs with contents: write and id-token: write but uses GitHub Actions by
mutable version tags (for example pnpm/action-setup@v5 and actions/setup-node@v6). If any of
these tags are ever retargeted or an upstream action is compromised, that code would execute with
the ability to publish to npm and push to the repository.

Code

.github/workflows/npmpublish.yml[R76-86]

Evidence

The publish job is explicitly granted high-privilege permissions, and it invokes multiple actions
via mutable version tags within the same job scope.

.github/workflows/npmpublish.yml[68-70]
.github/workflows/npmpublish.yml[72-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
High-privilege workflow steps are using third-party actions referenced by mutable tags. Mutable tags increase supply-chain risk because the referenced code can change without a PR.

## Issue Context
The `publish-npm` job has `contents: write` and `id-token: write`, so any action it runs inherits powerful capabilities.

## Fix Focus Areas
- .github/workflows/npmpublish.yml[68-86]

### Implementation direction
- Replace each `uses: owner/action@vX` with an immutable commit SHA for that release (optionally keep a comment with the intended version).
- Pin at minimum the actions used in `publish-npm` (checkout, setup-node, cache, pnpm/action-setup).
- Add/ensure Dependabot (or equivalent) updates GitHub Actions pins regularly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---