npm releases lack provenance

[tekumara]

OpenCodeReview Version

1.11.2

Operating System

macOS (Apple Silicon)

Installation Method

npm (global)

LLM Provider

Anthropic (Claude)

Bug Description

npm package releases lack provenance, but used to have provenance and so mise fails to install

mise use -g npm:@alibaba-group/open-code-review
npm:@alibaba-group/open-code-review@1.11.2 resolving                                                                                                                               ◡
mise ERROR Failed to install npm:@alibaba-group/open-code-review@latest: aube install failed: failed to resolve dependencies
  caused by: trust downgrade for @alibaba-group/open-code-review@1.11.2 (trustPolicy=no-downgrade): earlier published version 1.1.10 had provenance attestation but this version has no trust evidence

This is a supply-chain trust failure, not an ordinary version-resolution error. An earlier release had stronger trust evidence than the selected release. This can indicate a compromised or tampered release; it can also happen when a maintainer manually publishes, backports outside the trusted workflow, skips provenance for convenience, or uses a registry that strips metadata.

Before bypassing, inspect the package's npm release, source tag/commit, publisher identity, and tarball; compare the metadata with npmjs.org. Confirm the release is expected and nothing appears tampered with, then report inconsistent evidence to the relevant upstream owner. Package-release drift belongs with the maintainer; metadata present on npmjs.org but missing from a proxy or mirror belongs with that registry operator.

Only after review, add the narrowest affected `<package>@<version>` to `trust_policy_excludes` for this tool, e.g.:
  "npm:@alibaba-group/open-code-review" = { version = "latest", trust_policy_excludes = ["<package>@<version>"] }
A bare package name exempts every version. `mise settings npm.shell_out=true` uses the npm CLI and bypasses this check entirely, so it should be a last resort.

Investigation guide and known exceptions: https://aube.jdx.dev/security#trust-policy
mise ERROR Version: 2026.8.14 macos-arm64 (2026-08-25)
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information

Steps to Reproduce

n/a

Expected Behavior

npm packages published with provenance, ie: have the green tick... see https://docs.npmjs.com/viewing-package-provenance

Logs / Error Output

Additional Context

No response

[nitishagar]

Following up on the discussion in #1139: one way to restore provenance without putting anything on the release critical path is to decouple attestation from publishing entirely.

The self-hosted npm-publish job keeps doing what it does today (token auth, no id-token). A separate npm-attest job — GitHub-hosted, needs: npm-publish, but not a dependency of anything — runs npm attest prove/npm attest verify (npm ≥ 11.5) against the published versions and attaches the attestation after the fact. Because it is a leaf job:

• a queued hosted runner can no longer block a tag release (the exact problem @lizhengfeng101 described);
• provenance still fails loudly in CI if the attest job fails, so there is no silent downgrade — but a fixable rerun is just re-running the leaf job;
• the attestation is minted on a GitHub-hosted runner with id-token: write, which is what npm's provenance verification requires, so the self-hosted constraint is respected.

The one trade-off vs. publishing with --provenance: there is a window where the version exists unattested until the leaf job completes, so trustPolicy=no-downgrade consumers could still see a brief gap on fresh versions (a workflow that gates on the attest job's completion before announcing the release closes that operationally).

Happy to prototype this on top of #1139's archaeology if the direction sounds right — otherwise leaving it here as an option.

[tekumara]

Sounds reasonable, the trade-off seems fine, thanks for looking into this!

[hyy321]

Hi, I would like to work on this issue.
I plan to investigate the current npm release workflow and add a separate provenance attestation step on GitHub-hosted runners, while keeping the existing publish flow unchanged.
Please let me know if this direction matches the expected approach.

[hyy321]

Hi @lizhengfeng101,

I took a look at how npm provenance is generated and checked the current npm publish implementation.

The separate npm-attest approach does not seem to work with the current npm provenance flow. Provenance is generated during npm publish and uploaded together with the package metadata as a .sigstore attachment. I couldn't find a supported way to attach provenance to an already published npm package.

I also checked the current release workflow. The npm-publish job only depends on release and is not involved in creating the GitHub Release itself:

build → release → npm-publish

So moving only the npm-publish job back to a GitHub-hosted runner may be a better fit, while keeping the build and release jobs on self-hosted runners.

I will take a closer look at this approach before proposing a patch.