npm : la version 6.0.1 du gestionnaire de paquets officiel de Node.js. passe en @latest
La commande npm audit est désormais fonctionnelle

Le , par Marco46, Modérateur
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
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
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
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de koyosama koyosama - Membre éprouvé https://www.developpez.com
le 14/05/2018 à 4:04
Ouais tester et ça fait mal au cul.
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 14/05/2018 à 10:54
Merci pour ta contribution mais pourrais-tu développer stp ? :p
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 16/07/2018 à 19:52
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 »

 
Contacter le responsable de la rubrique Accueil