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

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


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


 Poster une réponse

Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 10/05/2018 à 14:55
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
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
Avatar de koyosama koyosama - Membre éclairé 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
Contacter le responsable de la rubrique Accueil