Automatic provenance generation not supported for provider: null

Dans GitHub Actions sans `permissions: id-token: write`, le message est « Provenance generation in GitHub Actions requires "write" access to the "id-token" permission » (les deux messages ont été reproduits avec npm 11.19.1) ; dans GitLab sans l’entrée `id_tokens`, il mentionne `SIGSTORE_ID_TOKEN` (texte tiré du code source de libnpmpublish). Il s’agit dans tous les cas d’erreurs `EUSAGE`. Le nom du fournisseur provient de la détection de CI de npm (`ci-info`).

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

Ce que cela signifie

`npm publish --provenance` crée une déclaration de provenance SLSA signée qui indique quel workflow de CI a construit le paquet. npm ne peut le faire que dans un système de CI pris en charge qui fournit une identité OIDC (GitHub Actions sur des runners hébergés par GitHub, GitLab CI sur des runners partagés) ; c’est cette identité que Sigstore inscrit dans le certificat de signature. `provider: null` signifie que npm n’a détecté aucune CI : la commande a été exécutée sur la machine d’un développeur ou dans une CI non prise en charge. Rien n’a été publié.

Pourquoi cela se produit

• Publication depuis un ordinateur portable

  fréquente

  `--provenance` (ou `provenance=true` dans `.npmrc`, ou `publishConfig.provenance`) défini pour un paquet qu’un mainteneur publie manuellement. La provenance sert à prouver un build de CI : elle ne peut donc pas être produite localement.

• Job de CI sans autorisation d’émettre un jeton OIDC

  fréquente

  GitHub Actions ne fournit le jeton qu’avec `id-token: write` ; GitLab, uniquement avec une entrée `id_tokens` dont l’audience est `sigstore`.

• Un système de CI pour lequel npm ne peut pas générer de provenance

  occasionnelle

  Jenkins, CircleCI, les runners auto-hébergés et d’autres systèmes sont détectés (le nom du fournisseur apparaît dans le message), mais ne sont pas pris en charge pour la provenance automatique.

Comment corriger l’erreur

1. 1.

   Publier depuis un workflow GitHub Actions

   Accordez `id-token: write`, exécutez le job sur un runner hébergé par GitHub et publiez avec `--provenance`. La publication de confiance de npm (trusted publishing, OIDC) peut remplacer entièrement le jeton 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 depuis GitLab CI

   Demandez un jeton d’ID avec l’audience `sigstore` sous `id_tokens` ; npm le récupère dans `SIGSTORE_ID_TOKEN`.

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

← Parcourir toute la base de données des erreurs de signature