Réponse en bref
Le changement npm du 30 septembre permet de déplacer les étiquettes avec des identifiants temporaires. Il comble une lacune concrète et invite à préciser qui peut promouvoir une version existante.
Une petite étape conservait un secret durable
GitHub a annoncé de nouvelles permissions npm dist-tag le 30 septembre 2026. La publication de confiance couvre désormais une opération qui peut intervenir après le dépôt d’un paquet : modifier ses étiquettes avec des identifiants OpenID Connect de courte durée. Pour les responsables conservant un jeton d’écriture uniquement afin de promouvoir ou de rétablir une version, une raison concrète de stocker ce secret disparaît.
Un processus de livraison ne se contente pas de fabriquer une archive. Il décide aussi quelle version disponible rencontre une personne ou une application lorsqu’elle demande un canal nommé. Cette décision peut suivre des essais, une approbation ou un déploiement progressif. Traiter la promotion comme une capacité distincte donne à ce changement davantage de portée que son simple réglage ne le laisse penser.
Une étiquette désigne une version et peut être déplacée
La référence npm explique que les étiquettes sont des alias de versions de paquets. Une installation ordinaire sans version ni étiquette explicite utilise latest ; un projet peut maintenir d’autres canaux, tels que beta ou next. Déplacer le pointeur change la version obtenue par une demande ultérieure sur ce canal. Cela ne nécessite pas de publier à nouveau une archive à chaque modification du pointeur.
Prenons l’exemple d’une version déjà vérifiée dans un canal de prépublication. La promouvoir peut consister à faire pointer le canal stable sur ce paquet existant ; revenir en arrière peut désigner une version précédente. Ces exemples sont explicatifs, sans correspondre à un incident rapporté. Ils montrent pourquoi le contrôle des étiquettes mérite un examen même si un processus ne peut pas déposer directement de nouveau paquet.
Le droit doit être accordé séparément
L’option Allow npm dist-tag est désactivée par défaut dans les configurations de confiance nouvelles et existantes. Le droit de publier directement ne l’accorde pas automatiquement. Une configuration limitée à la préparation peut aussi recevoir ce droit. Les opérations traditionnelles utilisant un jeton continuent de fonctionner : il s’agit donc d’une possibilité de migration, sans échéance immédiate de suppression de l’ancienne méthode.
GitHub précise qu’une identité OIDC est autorisée dès qu’elle correspond à une configuration dont le droit sur les étiquettes est activé. Il faut donc examiner ensemble les configurations pertinentes. Un droit large reste significatif même si un autre réglage est restrictif. La revue doit déterminer quel processus peut choisir la version d’un canal, au-delà de la seule capacité à construire le paquet.
L’identité du processus ne remplace pas sa gouvernance
La spécification OpenSSF des éditeurs de confiance décrit le principe général : le dépôt accepte une identité de tâche configurée plutôt qu’un secret réutilisable détenu par le responsable. La relation de confiance relie le registre et le fournisseur d’automatisation. Cela réduit la distribution et le renouvellement de secrets persistants, tout en reportant l’attention sur l’identité et les autorisations du processus.
Selon notre analyse, retirer un jeton simplifie une partie de la revue sans la terminer. Une tâche capable de déplacer une étiquette stable prend toujours une décision importante. L’équipe doit pouvoir préciser qui modifie cette tâche, quelles validations encadrent la promotion et comment corriger un pointeur erroné. La durée de vie des identifiants et le droit de livrer répondent à des enjeux liés, mais distincts.
Vérifier la version du client et l’opération réelle
La documentation npm demande la CLI 11.21.0 ou ultérieure dans la série 11, ou 12.2.0 ou ultérieure dans la série 12, pour cette fonction OIDC. Elle précise aussi que npm whoami ne teste pas les droits de publication de confiance. La vérification doit porter sur l’opération prévue. Réussir une authentification avec une autre commande ne démontre pas que les permissions sur les étiquettes sont correctes.
Une migration contrôlée peut consigner la version visée, effectuer le changement autorisé et vérifier le pointeur obtenu. La documentation distingue la lecture des étiquettes publiques de celle des paquets privés, qui exige aussi le droit approprié. Installer des dépendances privées peut toujours nécessiter un jeton de lecture. Supprimer une ancienne clé suppose donc de recenser au préalable ses usages effectifs.
Des droits plus précis clarifient les responsabilités
Le tableau sépare préparation, publication directe et gestion des étiquettes, car une formule générale comme accès à la livraison masque des différences importantes. Une équipe peut autoriser la fabrication d’un artefact sans sa publication, ou réserver la promotion à un processus contrôlé. Ce sont des choix d’organisation ; la nouveauté ne définit pas elle-même la politique d’approbation interne.
L’intérêt concret est de formuler une question plus précise : quelle identité peut déplacer quel canal, et comment ce geste sera-t-il vérifié ? L’annonce ne démontre pas qu’un projet migré est à l’abri des attaques sur sa chaîne logicielle. Elle permet de retirer un secret persistant tout en conservant une fonction normale et utile de gestion des versions.
| Opération | Règle de confiance | Point à examiner |
|---|---|---|
| Préparer un paquet | Accessible à un éditeur de confiance configuré | La préparation ne vaut pas approbation |
| Publier directement | Autorisation séparée | Limiter aux processus prévus |
| Gérer les dist-tags | Nouveau droit désactivé par défaut | Contrôle les canaux, dont latest |
| Installer des dépendances privées | Hors de cette nouvelle capacité OIDC | Un jeton de lecture peut rester nécessaire |
Questions et réponses
La publication de confiance autorise-t-elle automatiquement les étiquettes ?
Non. Le responsable doit activer Allow npm dist-tag sur la configuration souhaitée. Selon l’annonce du 30 septembre, le nouveau droit est désactivé par défaut sur les configurations anciennes et nouvelles.
Un processus limité à la préparation peut-il recevoir ce droit ?
Oui. La gestion des étiquettes et la publication directe sont indépendantes. Un processus peut préparer des paquets et gérer leurs dist-tags sans être autorisé à exécuter une publication directe avec npm publish.
Peut-on supprimer immédiatement tous les anciens jetons ?
Il faut d’abord vérifier leurs usages. Les opérations traditionnelles restent possibles et certaines tâches, notamment l’installation de dépendances privées, peuvent nécessiter leurs propres identifiants. Seuls les secrets dont les usages résiduels sont maîtrisés devraient être retirés.