1 package has an invalid registry signature:

Forme au pluriel : « N packages have invalid registry signatures: ». Une signature dont le `keyid` ne figure pas parmi les clés du registre échoue avec le code `EMISSINGSIGNATUREKEY` (« …has a registry signature with keyid: … but no corresponding public key can be found ») ; les attestations de provenance invalides sont listées sous « …has an invalid attestation ».

npm audit signatures (npm 9.5+) — registry signature check of installed packages

Ce que cela signifie

npm a téléchargé les clés de signature publiques du registre et vérifié la signature de registre de chaque paquet installé – une signature ECDSA portant sur `name@version:integrity` –, et pour au moins un paquet, la vérification a échoué. Soit les métadonnées du paquet (y compris le condensat d’intégrité de l’archive tarball) ont changé après leur signature par le registre, soit le registre depuis lequel vous avez installé signe avec des clés qu’il ne publie pas. npm liste les paquets concernés et termine par « Someone might have tampered with this package since it was published on the registry! ».

Pourquoi cela se produit

• Un registre miroir ou proxy sert des métadonnées différentes

  fréquente

  Des miroirs privés (Verdaccio, Artifactory, Nexus) qui réécrivent les URL des tarballs ou reconditionnent les paquets tout en conservant les signatures d’origine – ou qui signent avec leur propre clé sans la publier à `/-/npm/v1/keys`.

• Les métadonnées ou le contenu du paquet ont été modifiés

  occasionnelle

  Le condensat d’intégrité ou le tarball diffère de ce que le registre a signé. Considérez le paquet comme compromis jusqu’à preuve du contraire.

• Clés récupérées ailleurs

  occasionnelle

  Avec un registre personnalisé, npm récupère les clés auprès de ce registre. S’il renvoie les clés du registre public tout en servant des métadonnées re-signées (ou l’inverse), la vérification échoue.

Comment corriger l’erreur

1. 1.

   Comparer avec le registre public

   Si l’intégrité indiquée par le registre public pour la même version correspond à votre fichier de verrouillage, le problème vient du miroir ; sinon, c’est le fichier de verrouillage ou le paquet qui a été modifié.

   # Same version, straight from the public registry: does the integrity match your lockfile?
   npm view left-pad-lite@1.0.0 dist.integrity --registry https://registry.npmjs.org/
   grep -A3 '"node_modules/left-pad-lite"' package-lock.json | grep integrity

2. 2.

   Exécuter la vérification en CI

   `npm audit signatures` après `npm ci` fait échouer le build en présence de dépendances non signées, mal signées ou dont la provenance ne correspond pas.

   # CI: fail the build on missing or invalid signatures and provenance
   - run: npm ci
   - run: npm audit signatures

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