Automatic provenance generation not supported for provider: null

No GitHub Actions sem `permissions: id-token: write`, a mensagem é “Provenance generation in GitHub Actions requires "write" access to the "id-token" permission” (ambas reproduzidas com o npm 11.19.1); no GitLab sem a entrada `id_tokens`, ela cita `SIGSTORE_ID_TOKEN` (texto do código-fonte da libnpmpublish). Todos são erros `EUSAGE`. O nome do provedor vem da detecção de CI do npm (`ci-info`).

npm publish --provenance (npm 9.5+) — libnpmpublish, code EUSAGE

O que significa

O comando `npm publish --provenance` cria uma declaração de proveniência SLSA assinada que informa qual fluxo de trabalho de CI fez o build do pacote. O npm só consegue fazer isso dentro de um sistema de CI compatível que forneça uma identidade OIDC (GitHub Actions em runners hospedados pelo GitHub, GitLab CI em runners compartilhados); essa identidade é o que o Sigstore coloca no certificado de assinatura. `provider: null` significa que o npm não detectou nenhum CI — o comando rodou na máquina de um desenvolvedor ou em um CI sem suporte. Nada foi publicado.

Por que acontece

• Publicação a partir de um notebook

  comum

  A opção `--provenance` (ou `provenance=true` no `.npmrc`, ou `publishConfig.provenance`) definida para um pacote que um mantenedor publica manualmente. A proveniência existe para comprovar um build de CI, por isso não pode ser gerada localmente.

• Job de CI sem permissão para emitir um token OIDC

  comum

  O GitHub Actions só fornece o token com `id-token: write`; o GitLab, só com uma entrada `id_tokens` cujo público-alvo é `sigstore`.

• Um sistema de CI para o qual o npm não consegue gerar proveniência

  ocasional

  Jenkins, CircleCI, runners auto-hospedados e outros são detectados (o nome do provedor aparece na mensagem), mas não têm suporte para proveniência automática.

Como corrigir

1. 1.

   Publicar a partir de um fluxo de trabalho do GitHub Actions

   Conceda `id-token: write`, rode em um runner hospedado pelo GitHub e publique com `--provenance`. A publicação confiável (trusted publishing) do npm, via OIDC, pode substituir totalmente o token do npm.

   name: release
   on: { release: { types: [published] } }
   permissions:
     contents: read
     id-token: write          # lets npm obtain the OIDC token Sigstore needs
   jobs:
     publish:
       runs-on: ubuntu-latest   # GitHub-hosted runner
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with: { node-version: 24, registry-url: "https://registry.npmjs.org" }
         - run: npm ci
         - run: npm publish --provenance --access public
           env: { NODE_AUTH_TOKEN: "${{ secrets.NPM_TOKEN }}" }

2. 2.

   Ou a partir do GitLab CI

   Solicite um token de ID com o público-alvo `sigstore` em `id_tokens`; o npm o lê de `SIGSTORE_ID_TOKEN`.

   publish:
     image: node:24
     id_tokens:
       SIGSTORE_ID_TOKEN:
         aud: sigstore
     script:
       - npm publish --provenance --access public

← Ver toda a base de erros de assinatura