Discussion :

[Marco46]

npm en version 5.7.0,
l'alignement vers les pratiques DevOps se poursuit.

npm de npm, Inc est à JavaScript ce que le célèbre Maven de la fondation Apache est à Java. Il fournit des outils de gestion du cycle de vie de l'application, et il s'adosse à un registre de packages pour gérer efficacement les dépendances d'exécution et de développement des projets JavaScript, qu'ils soient backend ou frontend.

npm est aussi le package manager par défaut de Node.js.

En dépit du foisonnement d'outils disponibles pour l'écosystème JavaScript et malgré les spécificités des développements backend et frontend, npm a su s'imposer comme la référence en la matière, notamment depuis que Bower arrive en fin de vie.

Le 8 février dernier, Laurie Voss a annoncé sur le compte Twitter de npm que le nombre de packages téléchargés chaque semaine avait atteint 4 milliards, publiant la courbe de l'évolution des téléchargements depuis 2013 :

Les premières versions de npm avaient de nombreux défauts (gestion du cache, gestion de la hiérarchie des packages, lenteurs dues à des téléchargements séquentiels des packages, gestion non déterministe des relations de dépendances...), aboutissant même à la création de Yarn, un gestionnaire de paquets s'adossant sur le registre npm et capable également d'utiliser celui de Bower.

Ces principaux problèmes ont été traités dans la version 5, au point de remettre en cause l'intérêt de l'usage de Yarn.


CHANGELOG condensé de la version 5 de npm et des différentes versions mineures :

v5.0.0 26/05/2017

• Amélioration très significative des performances en implémentant le téléchargement concurrentiel et une meilleure gestion de la mémoire. Les performances de npm se rapprochent de celles de Yarn.
• Une dépendance installée via npm install <nom-package> est désormais insérée par défaut dans le package.json. L'option --save devient donc dépréciée et une option --no-save a été ajoutée.
• Un nouveau fichier package-lock.json est désormais généré automatiquement à chaque usage de npm install s'il est manquant. Ce fichier joue le même rôle que le trop méconnu npm-shrinkwrap.json. Le package-lock.json n'étant pas destiné à être publié sur le registre avec son package, le shrinkwrap est conservé si l'auteur du package souhaite le publier sur le registre afin de forcer le verrouillage des dépendances de son package.
• Le CLI npm n'affiche plus l'arbre des dépendances complet dans la console, à la place un résumé plus simple et plus lisible est affiché.
• Réécriture complète du système de cache et d'intégrité (utilisation de SHA512). Si votre projet utilise une version inférieure de npm, un npm cache clean est nécessaire avant de jouer un npm install pour mettre à niveau votre projet. Ajout de la commande npm cache verify pour vérifier l'intégrité du cache. Ajout de nouvelles options à la commande npm cache (--prefer-offline, --prefer-online, et --offline). Gestion des accès concurrents au cache.

v5.1.0 06/07/2017

• La commande npm ls servant à lister les packages installés sur un projet affiche toutes les dépendances, ainsi que les dépendances manquantes.
• Le fichier package-lock.json se met à jour automatiquement lors de l'ajout d'une dépendance via npm install <package-name>.

v5.2.0 11/07/2017

• Ajout du binaire npx, écrit pour remplacer la commande npm run-script. En association avec le récent package node, il permet d'ajouter l'environnement Node.js souhaité aux dépendances de votre projet, et donc de choisir quelle version de Node.js utilisera votre projet indépendamment de la version globale installée sur votre machine.

v5.3.0 14/07/2017

• Beaucoup de corrections de bogues sur npx.

v5.4.0 23/08/2017

• Nouvelle fonctionnalité "did you mean" sur le CLI (Vérification des fautes de frappe sur les commandes à la manière du CLI de git).
• Corrections de bogues de npx sur Windows.

v5.5.0 04/10/2017

• Ajout de fonctionnalités de sécurité pour le registre (authentification à deux facteurs, gestion des tokens...).

v5.6.0 28/11/2017

• Ajout de la possibilité de générer un package-lock.json sans pour autant réinstaller les dépendances via une nouvelle option --package-lock-only sur la commande npm install.
• Corrections de bogues avec node9 empêchant l'exécution correcte de npm.

v5.7.0 21/02/2018

Et enfin le 21 février, l'équipe npm a publié la version 5.7.0 dont les apports principaux sont :

• npm install résout automatiquement les conflits levés par les git merge sur les fichiers package-lock.json et npm-shrinkwrap.json.
• Ajout d'une nouvelle commande npm ci. Cette commande doit être jouée dans le cadre d'une intégration continue à la place de npm install. Elle assure que l'installation des dépendances se fait exclusivement sur la base du fichier package-lock.json, et si l'installation n'est pas possible, elle sort en erreur permettant de faire échouer le job d'intégration continue proprement. Le répertoire node_modules/ est toujours réinstallé en intégralité.

Cette dernière fonctionnalité complète les efforts effectués tout au long du développement de la version 5 de npm pour obtenir un comportement rigoureux, consistant et compatible avec les pratiques promues par le mouvement DevOps.

L'équipe de développement indique par la voix de Rebecca Turner que les mises à jour futures arriveront à un rythme plus soutenu qu'auparavant, leur backlog étant manifestement chargé, ce qui n'augure que du bon compte tenu de la qualité des dernières versions.


Une nouvelle version du site d'exploration des packages en préparation

Notons également la publication d'une version preview du site d'exploration des packages.


Sources :
- Annonce sur le blog officiel.
- Notes de versions sur github.
- Compte Twitter de npm, Inc.

Et vous ?

Utilisez-vous npm ou un autre package manager pour vos projets ?
Préférez-vous Yarn à npm malgré les améliorations de la version 5 ?

[bilgetz]

Attention avec cette version, il semble que certain ai eu des problemes avec :
https://github.com/npm/npm/issues/19883

il faut passer en 5.7.1

[Michael Guilloux]

npm 5.7.0 retiré de la circulation à peine deux jours après sa sortie
la version 5.7.1 publiée pour corriger un problème critique

Comme nous l’avons annoncé récemment, l’équipe npm a publié la version 5.7.0 du gestionnaire de paquets de Node.js. Pour information, un gestionnaire de paquets est un système qui permet d'automatiser le processus d'installation, désinstallation, et de mise à jour de logiciels installés sur un système informatique. Il permet d'effectuer différentes opérations, comme l'utilisation de paquets provenant de supports variés (CD d'installation, dépôts sur internet, partage réseau…), la vérification des sommes de contrôle de chaque paquet récupéré pour en vérifier l'intégrité et la vérification des dépendances logicielles afin d'obtenir une version fonctionnelle d'un paquetage.

Il existe de nombreux gestionnaires de paquets en fonction des systèmes d'exploitation et plateformes de développement. NuGet par exemple est un gestionnaire de paquets conçu pour les plateformes de développement de Microsoft, y compris .NET. Pour les utilisateurs de JavaScript et Node.js, c'est le gestionnaire de paquets npm qui, depuis la version 0.6.3 de Node, fait partie de l'environnement et est donc automatiquement installé par défaut.

Pour revenir à npm 5.7.0, parmi ses principaux apports on notera la résolution automatique des conflits levés par les git merge sur les fichiers package-lock.json et npm-shrinkwrap.json, mais surtout l’introduction de la commande npm ci que l’équipe npm espère voir apporter un gros avantage pour les environnements d'intégration continue.

Certains utilisateurs qui se sont rués vers cette version du gestionnaire de paquets de JavaScript et Node.js ont toutefois eu une surprise désagréable. Sur Linux, un utilisateur a signalé sur GitHub avoir constaté que les autorisations critiques du système de fichiers ont été modifiées par la dernière version de npm.

« Ce problème est survenu depuis la sortie de 5.7.0 il y a quelques heures, [cette version] semble avoir complètement changé les permissions de mon système de fichiers et m'a obligé à corriger manuellement les permissions des fichiers et dossiers critiques », a-t-il rapporté. « En exécutant sudo npm en tant qu'utilisateur non root (les utilisateurs root n'ont pas le même effet), les permissions du système de fichiers sont fortement modifiées. Par exemple, si je lance les commandes sudo npm --help ou sudo npm update -g, mon système de fichiers change les propriétaires des répertoires tels que /etc, /usr, /boot, et d'autres répertoires nécessaires pour exécuter le système. Il semble que la propriété est récursivement attribuée à l'utilisateur qui exécute npm. »

D’autres utilisateurs sur d’autres plateformes ont confirmé avoir constaté des problèmes similaires après l’installation de npm 5.7.0 ; ce qui a suscité beaucoup d'interrogations sur la stabilité de npm 5.7.0. Certains ont indiqué que si vous regardez le dépôt de npm, vous remarquerez que npm 5.7.0 est une préversion et ne devrait donc pas être installée, et ils semblent avoir raison.

Quoi qu’il en soit, npm 5.7.1 a été publié avec un patch pour corriger ce problème critique. On ne sait pas encore ce qui s’est passé exactement pour que l’équipe npm annonce la sortie officielle de npm 5.7.0. S’il s’agit d’un incident, alors c’est au moins le deuxième depuis le début de cette année. Rappelons en effet que le 6 janvier, de nombreux paquets avaient soudainement disparu. L'équipe npm évoquait un incident opérationnel avec le registre npm qui a provoqué l'indisponibilité temporaire de 97 paquets pendant environ 30 minutes, et 9 paquets supplémentaires pendant environ trois heures.

L'incident a été causé par les systèmes de npm pour détecter les spams et les codes malveillants sur le registre. Les systèmes automatisés effectuent une analyse statique de plusieurs façons pour signaler des codes et auteurs suspects. Le personnel de npm passe ensuite en revue les éléments marqués pour savoir s’il faut empêcher la distribution des paquets concernés. Mais dans l’examen des éléments signalés avant l'incident, ils se sont trompés dans leur jugement. Et comme conséquence, cela a empêché la distribution du code légitime d'un éditeur aux développeurs dont les projets en dépendent.

L'erreur a été rapidement identifiée et des procédures ont été suivies pour annuler le blocage. Mais des actions entreprises de manière indépendante par des membres de la communauté ont compliqué le processus entamé par l'équipe npm pour annuler le blocage des paquets, et ont donc nécessité des étapes et du temps supplémentaires. Des changements immédiats ont par la suite été faits pour éviter que ce problème se reproduise à l'avenir.

Sources : Problèmes causés par npm 5.7.0, Sortie de npm 5.7.1

Et vous ?

Qu’en pensez-vous ?
Avez-vous eu le temps d’installer npm 5.7.0 ? Si oui, avez-vous rencontré des problèmes similaires ?

Voir aussi :

Un incident opérationnel a provoqué la disparition d'une centaine de paquets npm, l'équipe derrière le gestionnaire de paquets de Node.js s'explique
Node.js 8.9.0 LTS est disponible pour une utilisation en production et Node.js 9.0.0 à des fins de tests et d'expérimentation

[headmax]

Peut être une boulette dans une récursivité comme tu le dit en employant un chown -R user:user *

[Marco46]

Avez-vous eu le temps d’installer npm 5.7.0 ? Si oui, avez-vous rencontré des problèmes similaires ?

Wouaw ! Hier soir après avoir rédigé la news j'ai mis à jour mon npm et je me rappelle pas de quelle version j'ai installé. J'avais la tête dans le sac (ça m'a pris 3h pour rédiger la news) et je voulais absolument tester npx et l'exécution de node en tant que dépendance de projet ou dynamiquement via npm avant d'aller me coucher.

J'ai même pas fait gaffe à cette histoire :'(

Grand merci à Michael Guilloux pour le gros complément d'information !

EDIT : Moralité, ne jamais se fier au blog, toujours se fier aux notes de releases techniques !

[Luckyluke34]

Ajout d'une nouvelle commande npm ci. Cette commande doit être jouée dans le cadre d'une intégration continue à la place de npm install. Elle assure que l'installation des dépendances se fait exclusivement sur la base du fichier package-lock.json, et si l'installation n'est pas possible, elle sort en erreur permettant de faire échouer le job d'intégration continue proprement. Le répertoire node_modules/ est toujours réinstallé en intégralité.

Je suis pas expert de npm, mais c'est pas un gros bout de scotch avec un nom beaucoup trop conceptuel cette commande ?

[Marco46]

Je comprends pas trop ta question/remarque.

Dans une CI quand tu veux builder un tag donné, tu veux que le résultat soit invariable dans le temps, y compris en tenant compte des dépendances, et des dépendances des dépendances, et des dépendances des dépendances des dépendances, etc ...

Cette commande permet de réaliser ça, et elle permet surtout de forcer l'équipe de dev à gérer ses dépendances de manière stricte. Si un DevOps impose l'usage de npm ci sur son job Jenkins de build du livrable, l'équipe de dev est obligée :
- de fixer toutes ses dépendances.
- d'avoir un package-lock.json à jour.

Sinon la commande exit en erreur, et le job est en échec.

Sans cette commande ce n'est pas garanti.

[Luckyluke34]

Je ne remets pas en cause l'utilité mais le fait de l'appeler npm ci. Il y aurait peut-être eu moyen de trouver un nom qui reste agnostique par rapport au contexte extérieur. Continuous Integration ne me parait pas faire partie du vocabulaire qui devrait être utilisé dans des primitives d'un package manager. Là ça fait très "fan service magique rien que pour vous"...

[Marco46]

npm 5.8.0 passe en @latest
intégration de contributions communautaires et travail sur la nouvelle commande npm ci

Poursuivant son cycle bimensuel d'amélioration continue, l'équipe gérant npm a publié en @latest la version 5.8.0 du CLI.

Cette version est désormais la version installée par défaut lors de l'exécution d'un npm i npm.

Elle embarque notamment :

• plusieurs contributions de la communauté ;
• un travail important sur la nouvelle commande npm ci destinée à l'utilisation de npm au sein d'une intégration continue ;
• diverses corrections de bogues ;
• une mise à jour de la documentation du CLI ;
• des mises à jour de dépendances.

Contributions communautaires notables

Ajout du package detect-newline du célèbre sindresorhus permettant de ne plus utiliser par défaut le caractère LF (connu aussi sous la forme de \n dans les chaînes de caractères) comme caractère de fin de ligne lors de l'enregistrement des fichiers package.json, package-lock.json et npm-shrinkwrap.json. Cette contribution a pour effet de rendre npm agnostique sur le sujet des fins de lignes.

Support du standard NO_COLOR, pour permettre de désactiver les couleurs ANSI via la présence d'une simple variable d'environnement nommée NO_COLOR permettant d'éviter de configurer chaque CLI indépendamment.

Message d'erreur plus détaillé lorsque npm échoue lors de la lecture des fichiers package-lock.json et npm-shrinkwrap.json au lieu d'un laconique JSON parse error.

Support de l'argument --no-proxy pour le CLI en plus du support de la variable d'environnement NO_PROXY. Cet argument sert à définir une liste d'exclusion des domaines qui ne doivent pas être concernés par la configuration éventuelle d'un proxy via les variables d'environnement HTTP_PROXY et HTTPS_PROXY. Avec cet ajout on peut passer par le CLI plutôt que par une variable d'environnement.

Meilleur support des clefs de variables d'environnement dans le fichier .npmrc. Cf explications détaillées dans les commentaires de la pull request.

Message d'erreur plus détaillé lors des erreurs levées par des problèmes de permissions d'accès (EPERM/EACCES).

Améliorations de npm ci

C'était la principale nouveauté de la version précédente.

Les benchmarks effectués par la communauté montrent des gains de temps d'exécution d'un facteur 2 à 5 rendant cette commande plus rapide que Yarn dans un contexte d'intégration continue.

La version 5.8.0 contient de nouvelles améliorations de performance, quelques corrections et une meilleure gestion de la jauge de progression dans le CLI.

Versions suivantes publiées en @next

Les versions 5.9.0 et 6.0.0 ont été publiées en pre-release. Nous y reviendrons en détail lors de leur passage en @latest.

Sources : Notes de version pour la v5.8.0, Article sur le blog officiel

Et vous ?

Qu’en pensez-vous ?
Avez-vous eu le temps d’installer npm 5.8.0 ?

Voir aussi :

Un incident opérationnel a provoqué la disparition d'une centaine de paquets npm, l'équipe derrière le gestionnaire de paquets de Node.js s'explique
Node.js 8.9.0 LTS est disponible pour une utilisation en production et Node.js 9.0.0 à des fins de tests et d'expérimentation

[Marco46]

npm 6.0.0, le gestionnaire de paquets officiel de Node.js. passe en @latest,
et se concentre désormais sur la sécurité

En parallèle de la publication de Node.js 10, l'équipe gérant npm a publié en @latest la version 6.0.0 du CLI npm.

Cette version est désormais la version installée par défaut lors de l'exécution d'un npm i npm.

Cette version embarque avec elle les nouvelles fonctionnalités des versions 5.9 et 5.10 qui sont encore à l'heure où j'écris cette actualité en pre-release (c'est-à-dire toujours taguées en @next).

Les nouveautés de la version 5.9

• une nouvelle commande npm view <package> qui propose un affichage humainement lisible des principales informations des packages ;
• les commandes npm pack et npm publish affichent désormais un compte rendu très léger de l'artefact généré (l'archive tar.gz) destiné à être poussé sur le registre npm ;
• un nouveau driver pour gérer les conflits de fusion git sur le package-lock.json lors de l'exécution la commande npm install. Ce driver s'installe au global de cette manière : npx npm-merge-driver install -g ;
• diverses corrections de bogues ;
• des mises à jour de dépendances.

Les nouveautés de la version 5.10

• la commande npm view <package> affiche désormais la somme de contrôle (shasum) et l'intégrité (integrity) du package. L'intégrité répond à la spécification du W3C Subresource Integrity grâce au package ssri, le shasum est conservé à titre de solution de repli si le registre n'a pas calculé l'intégrité du package ;
• ajout d'une commande npm cit sur le modèle de npm it qui joue donc un npm ci suivi d'un npm test ;
• diverses corrections de bogues ;
• des mises à jour de dépendances.

Un mot sur le champ integrity du package.json

Il est important de savoir que l'algorithme SHA1 a été cassé en 2017.

Ce champ permet au CLI npm de vérifier l'intégrité d'un package téléchargé sur votre cache local (lorsque vous effectuez un npm i <package>) au moyen d'un algorithme de hashage sécurisé (SHA512) et dans le pire des cas avec le shasum classique présent de longue date dans les informations des packages.

Outre cette vérification, l'équipe npm prévoit d'ajouter une fonctionnalité de vérification de signature électronique des packages publiés sur son registre. Car bien que la vérification d'une somme de contrôle permette de vérifier l'intégrité d'un fichier téléchargé, elle reste vulnérable à une attaque de type "homme du milieu" ("man in the middle").

Un attaquant parvenant à placer un proxy entre le registre et vous pourrait en théorie ajouter un code malveillant dans le package que vous souhaitez télécharger tout en relaculant les sommes de contrôles.

Pour l'heure, l'équipe npm a publié sa clef PGP et la procédure détaillée pour effectuer cette vérification manuellement, une commande dédiée ou un outil indépendant sera publié dans un futur proche.

La signature électronique effectuée porte sur l'identifant du package (<package>@<version>, par exemple npm@6.0.0) concaténé au champ integrity ce qui donne <package>@<version>:<integrity>.

Notons également que pour l'heure peu de packages du registre bénéficient de cette signature stockée dans le champ npm-signature. Le processus de signature est couteux à l'échelle du registre, il est donc effectué lentement au fil de l'eau.

npm inc s'offre Lift Security et sa plateforme NSP

Le 10 avril dernier, npm inc a annoncé avoir racheté la société Lift Security et sa plateforme NSP.

La Node Security Platform est un service de recensement des vulnérabilités connues sur les packages présents dans le registre npm.

La liste des vulnérabilités connues est consultable à cette adresse.

Le but de cet investissement est de fournir une nouvelle commande npm audit au CLI permettant de lister toutes les vulnérabilités connues dans vos dépendances.

Les nouveautés de la version 6

• support natif des hooks npm (port de wombat) ;
• intégration des packages create-x dans la commande npm init. Les create-x sont des packages dédiés à la génération d'applications. Par exemple le très connu create-react-app permet de générer un projet de démarrage pour react. En intégrant l'exécution de ce type de package à npm init, cela permet au développeur de partir de la création d'un nouveau projet via npm, donc de configurer son propre package.json tout en déclarant quel package create-x il souhaite utiliser, lequel sera exécuté dans la foulée. Par exemple npm init react-app abouti à la génération de votre package.json puis à l'exécution de create-react-app ;
• ajout de la commande npm audit qui comme expliqué dans le paragraphe précédent fournit un audit de sécurité des dépendances de votre projet. Cette fonctionnalité sera pleinement fonctionnelle d'ici quelques semaines, l'application gérant le registre n'ayant pas encore été mise à jour pour supporter cette fonctionnalité. L'exécution de cette commande aboutit pour l'heure à ce message d'erreur : Your configured registry (https://registry.npmjs.org/) does not support audit requests. ;
• les versions taguées deprecated des packages ne sont plus installées lorsque c'est possible ;
• les commandes npm update et npm outdated tiennent désormais compte du tag latest ;
• abandon du support de Node.js 4 et 7 ;
• diverses corrections de bogues ;
• des mises à jour de dépendances.

Les prochaines versions

L'équipe npm prévoit la livraison de plusieurs versions mineures pour la version 6 contenant entre autres un système d'alias pour les packages et une optimisation importante de performance pour la commande npm install (via une exécution masquée de npm ci lorsque c'est possible, c'est à dire lorsque package-lock.json est en phase avec le package.json).

Ensuite dans le courant de l'année, une version 7 verra le jour avec de nombreuses nouveautés :

• une intégration plus poussée de la gestion des templates d'application (les create-x) dans npm init ;
• des changements sur la manière dont npm gère les permissions systèmes ;
• une réécriture de la commande npm link ;
• etc.

Sources : les notes de versions (v5.9.0-next.0, v5.10.0-next.0, v6.0.0-next.0, v6.0.0-next.1, v6.0.0-next.2), Annonce officielle de la version 6 de npm, et Après npm 6, le futur du CLI npm .


Et vous ?

Que pensez-vous de toutes ces nouveautés ?
Avez-vous eu le temps d’installer npm 6.0.0 ?
Êtes-vous inquiets des éventuels problèmes de sécurité posés par l'usage de npm ?

Voir aussi :

Sortie de Node.js 10.0.0 avec le support officiel de N-API et OpenSSL 1.1.0, la version LTS de la série 10.x est prévue pour octobre 2018

Un incident opérationnel a provoqué la disparition d'une centaine de paquets npm, l'équipe derrière le gestionnaire de paquets de Node.js s'explique

Node.js 8.9.0 LTS est disponible pour une utilisation en production et Node.js 9.0.0 à des fins de tests et d'expérimentation

[Marco46]

npm 6.0.1 passe en @latest,
la commande npm audit est désormais fonctionnelle

Avec la sortie de la version 6 du CLI et le rachat de la Node Security Platform de Lift Security (voir actualité précédente), l'équipe npm met l'accent sur la sécurité.

Ces efforts s'orientent dans deux directions, l'audit des failles de sécurité au travers de la NSP via la nouvelle commande npm audit et la signature électronique des paquets du registre via PGP. Si ce dernier point nécessite encore beaucoup de travail, la commande npm audit, elle, devient fonctionnelle.

Les nouveautés de la version 6.0.1

Il y a quelques heures, Rebecca Turner de la team npm a publié la version 6.0.1 du CLI en @latest.

Outre les habituelles montées de version de dépendances, cette version propose :

• un meilleur support des vieux fichiers npm-shrinkwrap.json publiés sur le registre ;
• une correction sur la gestion de l'interruption de l'installation via CTRL+C ;
• des améliorations de la commande npm audit.

npm audit devient fonctionnelle

Le 8 mai dernier, Adam Baldwin, le head of security de npm inc et fondateur de la NSP a publié un article sur le blog npm décrivant le fonctionnement de la commande.

Son article n'étant pas très interactif, je vous propose de tester en quelques minutes cette fonctionnalité.

Il est nécessaire d'avoir une version du CLI à jour (généralement installée en global) : npm i -g npm aboutira à l'installation de la dernière version stable, c'est à dire la 6.0.1.

N'importe quelle version de Node.js supérieure ou égale à la version 6 fera l'affaire pour ce test.

Dans un nouveau répertoire, ajoutez un fichier package.json tout simple :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
{
  "name": "dev.com-test-npm-audit",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "start": "node index"
  },
  "dependencies": {
    "lodash": "4.17.4"
  }
}

Le fichier index.js est optionnel pour notre test, il permet simplement d'exécuter lodash pour vérifier son installation, par exemple :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
'use strict';
 
const _ = require('lodash');
 
console.log('1+1 = ', _.add(1, 1));

Notons que j'ai ajouté une version obsolète de lodash, la 4.17.4 à dessein, cette version contient une vulnérabilité patchée en 4.17.5.

Exécutons npm install.

Premier changement, la commande d'installation des paquets effectue un mini audit par elle-même :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
$ npm install
npm WARN dev.com-test-npm-audit@1.0.0 No description
npm WARN dev.com-test-npm-audit@1.0.0 No repository field.
npm WARN dev.com-test-npm-audit@1.0.0 No license field.
 
added 1 package from 2 contributors in 1.034s
[!] 1 vulnerability found [1 packages audited]
    Severity: 1 Low
    Run `npm audit` for more detail

Nous savons donc désormais si un paquet installé contient une vulnérabilité référencée par la NSP.

La commande npm audit fournit plus de détails :

$ npm audit

=== npm audit security report ===

# Run npm install lodash@4.17.10 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low │ Prototype Pollution │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/577 │
└───────────────┴──────────────────────────────────────────────────────────────┘



[!] 1 vulnerability found - Packages audited: 1 (0 dev, 0 optional)
Severity: 1 Low

Pour chaque paquet, le rapport décrit la vulnérabilité en donnant sa sévérité (ici faible), son type (ici Prototype Pollution), quel paquet installé est en dépendance (ici c'est lui même à savoir lodash) et donne un lien sur la NSP, lequel donne un peu plus de détails.

Le rapport propose aussi une version du paquet concerné à installer pour corriger la vulnérabilité.

Notez que cette nouvelle commande ne s'exécutera pas en l'absence d'un fichier package-lock.json correctement constitué. Il est donc absolument nécessaire d'avoir fait le ménage dans ses dépendances pour pouvoir bénéficier de cette fonctionnalité.


Sources : les notes de versions (v6.0.1), Annonce de la 6.0.1, et présentation de la commande npm audit sur le blog officiel.


Et vous ?

Que pensez-vous de cette nouvelle fonctionnalité ?
Avez-vous eu le temps d’installer npm 6.0.1 ?
Êtes-vous inquiets des éventuels problèmes de sécurité posés par l'usage de npm ?

Voir aussi :

npm : une porte dérobée a été découverte dans le paquet getcookies

[koyosama]

Ouais tester et ça fait mal au cul.

[Marco46]

Merci pour ta contribution mais pourrais-tu développer stp ? :p

[Marco46]

npm 6.2.0, passe en @latest,
et quatre news d'importance autour

Si les développements du CLI npm se sont beaucoup calmés ces dernières semaines, 2 nouvelles versions ont été publiées et surtout de nombreuses nouvelles et évènements sont venus émailler l'actualité du gestionnaire de paquet.

Les nouveautés de la version 6.1.0

La principale nouvelle fonctionnalité est la commande npm audit fix.

Cette commande permet de mettre à jour votre package.json et vos dépendances en respectant la philosophie semver, et ce sur la base du résultat du rapport d'audit.

La norme semver a pour principe de publier les hotfix de bugs et les patchs de sécurité en tant que version "patch", c'est-à-dire en n'incrémentant que le dernier numéro de version sur les trois disponibles afin de limiter l'impact de la montée de version à ce seul correctif.

Évidemment le respect de ce principe est à la charge du mainteneur du paquet mais la commande npm audit fix respectant cette idée générale, elle n'effectuera aucune montée de version mineure ou majeure sans la demande explicite de l'utilisateur.

Autres fonctionnalités mineures, la possibilité d'afficher l'audit au format json (npm audit --json).

Lors de l'exécution de la commande npm install le nombre de paquets audités est désormais affiché. Le rapport d'audit a été revu.

Le célèbre John-David Dalton (auteur de Lodash) a ajouté à la commande npm init le support des URL git, des chemins, des URL et des paquets versionnés.

Cette contribution enrichit la fonctionnalité de gestion des create-app ajoutée dans la version 6.0.0 du CLI npm.


Les nouveautés de la version 6.2.0

Une petite livraison avec seulement 2 nouvelles fonctionnalités.

Ajout d'une option --parseable sur la commande npm audit pour permettre de chainer facilement des commandes grep ou awk.

Ajout du support de la signature des commits git lors de l'exécution de npm version via l'option de configuration npm sign-git-commit.

Cette nouvelle option s'ajoute à sign-git-tag qui était déjà disponible.


Au-delà des nouvelles versions du CLI, différents évènements autour de l'écosystème npm ont eu lieu ces dernières semaines.


Le Node Security Platform service sera décommissionné le 30 septembre 2018

Suite à l'acquisition de Lift Security et de sa plateforme NSP, l'équipe npm a ajouté la fonctionnalité npm audit à son CLI fusionnant en quelque sorte la NSP au registre npm.

La plateforme web de la NSP n'a donc plus de raison d'être.

Les clients payants de la NSP seront transférés aux services payants de la plateforme npm.


npm se dote d'un forum discourse

L'équipe npm estime que le bug tracker de github et son système d'issue est trop primitif pour leur besoin.

Ils ont donc décidé de se doter d'un forum de type Discourse mieux adapté pour gérer leur type de communauté.

Ainsi, les anciens dépôts npm/npm (code source du CLI), npm/www (issues à propos du site npm), npm/registry (issues à propos du registre npm) ont été archivés.

Un nouveau dépôt pour le code source du CLI a été ouvert sur npm/cli. Il contient donc le code source du CLI mais ne permet pas la saisie d'issues.

Désormais les rapports de bogues et les demandes de nouvelles fonctionnalités doivent se faire sur le forum pour être discutés et sont formalisés plus sérieusement via un système de RFC qui existait déjà avant ce changement de fonctionnement.


npm rejoins ECMA International et donc le TC39

Le TC39 a pour rôle de débattre, de proposer puis de définir le standard ECMAScript qui est ensuite implémenté dans les différents moteurs d'exécution lesquels sont alors utilisés dans les navigateurs et par Node.js.

npm est devenu en 6 ans d'existence une brique indispensable de l'écosystème JavaScript. Utilisé par 11 millions de développeurs JavaScript de par le monde, c'est le package manager par défaut du backend, et c'est également désormais le plus utilisé pour le frontend.

En prenant part aux discussions sur l'avenir de JavaScript, npm souhaite influer sur les décisions qui seront prises et qui impacteraient le périmètre du package manager et du tooling autour.


Sources : Billets sur le blog officiel à propos de la v6.1.0, de la v6.2.0, de la fermeture de la NSP, des changements sur la gestion de la communauté et de l'arrivée de npm au TC39 .

Et vous ?

Que pensez-vous de toutes ces nouveautés ?
Avez-vous eu le temps d’installer la dernière version de npm ?
Que pensez-vous de la stratégie de npm de déplacer le bug tracker et les demandes de fonctionnalités de github vers un forum ?
Que pensez-vous de l'intérêt de npm pour le TC39 et son processus de normalisation du JavaScript ?

Voir aussi :

Un paquet npm, gestionnaire de paquets pour la bibliothèque populaire JavaScript Node.js, a été infecté par un hacker
Un développeur JavaScript estime que l'écosystème Node.js est « chaotique et peu sûr »