Automatic provenance generation not supported for provider: null

En GitHub Actions sin `permissions: id-token: write`, el mensaje es «Provenance generation in GitHub Actions requires "write" access to the "id-token" permission» (ambos reproducidos con npm 11.19.1); en GitLab sin la entrada `id_tokens`, menciona `SIGSTORE_ID_TOKEN` (texto tomado del código fuente de libnpmpublish). Todos son errores `EUSAGE`. El nombre del proveedor procede de la detección de CI de npm (`ci-info`).

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

Qué significa

`npm publish --provenance` crea una declaración de procedencia SLSA firmada que indica qué flujo de trabajo de CI compiló el paquete. npm solo puede hacerlo dentro de un sistema de CI compatible que proporcione una identidad OIDC (GitHub Actions en runners alojados en GitHub, GitLab CI en runners compartidos); esa identidad es lo que Sigstore incluye en el certificado de firma. `provider: null` significa que npm no detectó ningún sistema de CI: el comando se ejecutó en el equipo de un desarrollador o en un sistema de CI no compatible. No se publicó nada.

Por qué ocurre

• Publicar desde un portátil

  frecuente

  `--provenance` (o `provenance=true` en `.npmrc`, o `publishConfig.provenance`) activado para un paquete que un mantenedor publica manualmente. La procedencia sirve para demostrar una compilación en CI, así que no se puede generar en local.

• Trabajo de CI sin permiso para emitir un token OIDC

  frecuente

  GitHub Actions solo proporciona el token con `id-token: write`; GitLab, solo con una entrada `id_tokens` cuya audiencia sea `sigstore`.

• Un sistema de CI para el que npm no puede generar la procedencia

  ocasional

  Jenkins, CircleCI, los runners autoalojados y otros se detectan (el nombre del proveedor aparece en el mensaje), pero no son compatibles con la procedencia automática.

Cómo solucionarlo

1. 1.

   Publicar desde un flujo de trabajo de GitHub Actions

   Concede `id-token: write`, ejecuta el trabajo en un runner alojado en GitHub y publica con `--provenance`. La publicación de confianza de npm (trusted publishing, mediante OIDC) puede sustituir por completo el token de 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.

   O desde GitLab CI

   Solicita un token de ID con la audiencia `sigstore` en `id_tokens`; npm lo toma de `SIGSTORE_ID_TOKEN`.

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

← Explorar toda la base de datos de errores de firma