Changements incompatibles à venir dans npm v12

• Dans npm v12, les valeurs par défaut liées à la sécurité de npm install passent d’une exécution/interprétation automatique à un modèle d’autorisation explicite, avec des avertissements disponibles à l’avance dans npm 11.16.0 et versions ultérieures
• La valeur par défaut de allowScripts passe à désactivée, ce qui bloque l’exécution des scripts preinstall, install, postinstall des dépendances qui n’ont pas été explicitement autorisées, ainsi que le node-gyp rebuild implicite et les scripts prepare des dépendances git, file et link
• Utiliser npm approve-scripts --allow-scripts-pending pour voir quels paquets seront bloqués, puis définir ce qui est autorisé ou bloqué avec npm approve-scripts et npm deny-scripts, avant de commit l’allowlist générée dans package.json
• La valeur par défaut de --allow-git passe à none, ce qui interrompt la résolution des dépendances Git directes et transitives qui n’ont pas été explicitement autorisées avec --allow-git
• Fermeture d’un chemin d’exécution de code par lequel le .npmrc d’une dépendance Git pouvait écraser l’exécutable Git même lorsque --ignore-scripts était utilisé
• La valeur par défaut de --allow-remote passe à none, ce qui interrompt la résolution des dépendances par URL distante, comme les tarballs https, qui n’ont pas été explicitement autorisées avec --allow-remote
• Les valeurs par défaut de --allow-file et --allow-directory ne changent pas dans npm v12
• La procédure de préparation consiste à passer à npm 11.16.0 ou ultérieur, à exécuter une installation normale pour examiner les avertissements, à n’approuver que les paquets de confiance, puis, après la mise à niveau, à ne continuer à exécuter que les scripts approuvés
• Documentation associée : npm approve-scripts, npm deny-scripts, allow-scripts config

[GN⁺]

Commentaires sur Hacker News

• Je ne sais pas comment j’ai pu rater le fait que npm a été racheté par GitHub, mais soudain beaucoup de choses commencent à s’expliquer
  J’ai du mal à imaginer pire foyer pour un composant aussi important de l’écosystème Node

  • Apparemment, ça date de 2020
    https://github.blog/news-insights/company-news/npm-is-joinin...
  • C’était déjà assez terrible avant le rachat
  • Ça ressemble à une dégradation du service et à une prise de contrôle, un positionnement stratégique en vue d’une pression future sur la rentabilité
    « embrace, extend, extinguish »
    https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

• Les scripts postinstall auraient dû être supprimés depuis longtemps, c’est un cancer des paquets NPM
  Il y a bien trop de postinstall profondément imbriqués, non contrôlés, qui s’exécutent aléatoirement quand on récupère quelque chose
  Je ne sais pas qui a pu trouver que c’était une bonne idée à l’époque

  • Je ne suis pas sûr de bien comprendre le fond de l’inquiétude autour des scripts post-install
    En général, le code des dépendances packagées finit de toute façon par être exécuté à un moment donné, souvent avec les mêmes privilèges que le processus d’installation
    Du coup, ces scripts de configuration peuvent, pour le meilleur ou pour le pire, simplement déplacer leur point d’entrée de npm vers l’endroit où se produit un import ou un require
    À moins que tout l’écosystème ne migre vers un environnement sandboxé façon Deno, au mieux ça ressemble à une petite friction. C’est peut-être le plan, cela dit
  • Il ne faut surtout pas faire ça, il y a beaucoup de cas d’usage valables
    L’exemple qui me vient tout de suite est https://www.npmjs.com/package/patch-package
    J’espère que l’hystérie actuelle ne débouchera pas sur ce genre de décision absurde

• J’ai l’impression que ce sujet a dû être discuté des centaines de fois en interne chez NPM depuis sa publication il y a 10 ans
  À cause de Shai Halud, c’est désormais trop gros pour être ignoré

  • J’aime bien l’idée que l’histoire de JavaScript soit en gros une concentration de mentalité développeur
    « je corrigerai ça plus tard » finit presque toujours en « merde, il faut qu’on corrige ça maintenant »
  • Bien, maintenant c’est au tour de Python

• Je me demande si les versions Node LTS actuelles, de mémoire 22, 24, 26, vont recevoir npm v12 dans leur bundle pour bénéficier de ce correctif de sécurité
  Pour l’instant elles incluent toutes npm v11

  • Il y a déjà eu par le passé des mises à niveau majeures de npm dans des releases intermédiaires de Node
    npm est passé de 9 à 10 dans v18.19.0[1] et v20.10.0[2]
    [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
    [2]: https://nodejs.org/en/blog/release/v20.10.0
  • On peut y voir un changement de posture de sécurité puisque la valeur par défaut change, mais le correctif de sécurité lui-même est déjà applicable par tout le monde
    Comme l’indique l’article, il suffit de définir les bons paramètres par défaut
    Le meilleur aspect de ce changement, c’est qu’avec ce nouveau défaut, les paquets pénibles qui supposent que ces options sont activées dès qu’un nouveau développeur lance simplement install vont casser immédiatement
    Ça peut par exemple forcer l’arrêt de la pratique consistant à présumer que les scripts peuvent s’exécuter

• Ce n’est pas totalement clair à la lecture de l’article, mais la liste d’autorisation des scripts semble prendre en charge une autorisation par paquet plutôt qu’un réglage global
  Ça devrait faciliter le maintien de règles à l’échelle d’une organisation pour n’autoriser les scripts que sur certains paquets
  Je me demande s’il existe un linter capable d’empêcher ce type de valeurs par défaut non sûres dans la configuration du gestionnaire de paquets

  • Un grep, ça ne suffirait pas ?

• Je me demande s’il y a encore une raison d’utiliser Yarn
  Je ne sais pas si Yarn a aussi mis en place des protections contre les attaques de supply chain
  Jusqu’ici je ne connaissais que pnpm, donc c’est bien de voir npm s’aligner aussi

  • Bien sûr que oui
    La dernière release majeure de Yarn, la 4.x, garantit un comportement déterministe presque à l’excès, et on peut s’attendre à un comportement cohérent dans toute l’équipe
    Côté fonctionnalités, il y a plein de petits détails qui, une fois qu’on s’y habitue, finissent par faire une vraie différence
    La prochaine release majeure va continuer dans la même direction avec de meilleures performances, ainsi que des fonctionnalités qui n’ont pas pu être implémentées jusqu’ici précisément parce qu’elles dépendaient de ces gains de performance
    Pour référence, je suis le mainteneur principal de Yarn
  • J’ai travaillé sur un projet qui utilisait Yarn depuis ses débuts jusqu’à la v3, et c’est extrêmement lent mais ça fonctionne
    Il y a aussi des fonctionnalités de protection de la supply chain
    J’ai fini par ne plus le supporter et je suis passé à pnpm, ce qui a rendu les installations bien plus rapides à la fois en CI et sur les machines de dev locales
    La migration m’a pris environ une journée avec l’aide d’un LLM
  • Un des points différenciants, c’est la stratégie d’installation optionnelle qui permet d’exécuter les paquets directement depuis des archives compressées au lieu de les décompresser dans node_modules
    https://yarnpkg.com/features/pnp
    C’est assez proche de l’usage de .jar en Java plutôt qu’une arborescence de répertoires de fichiers .class
    Cela dit, c’est un peu bricolé, et le support des éditeurs et outils est inégal
    Comme il y a beaucoup moins de petits fichiers, ça peut être particulièrement plus rapide si vous êtes contraint de travailler sous Windows
    On peut aussi mettre les archives dans le dépôt git, ce qui supprime la dépendance à Internet et au registre de paquets
  • Je ne sais pas ce que fait NPM, mais avec Yarn, l’installation des dépendances est bien plus rapide qu’avec NPM
  • Ceux qui downvotent mon commentaire peuvent aussi répondre à la question
    Je ne connais vraiment pas la réponse

• Je ne savais pas que npm appartenait à GitHub
  Ça explique pas mal de choses

  • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 mars 2020, 571 commentaires, 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin...
    Certaines réactions sont intéressantes à relire avec le recul
    Le commentaire le plus haut disait en gros : « Microsoft ne réussit pas tout, mais honnêtement le rachat de GitHub s’est bien mieux passé que prévu. Au lieu d’imposer à GitHub des politiques centrées sur Microsoft, Microsoft a davantage adopté des éléments de GitHub du point de vue produit. GitHub continue de fonctionner comme une entreprise distincte »
  • L’entreprise NPM était pratiquement au bord de la faillite en 2020
    Elle avait levé du capital-risque, mais n’avait pas réussi à trouver un modèle économique viable
    GitHub l’a rachetée pour sauver l’écosystème, et cette acquisition n’a quasiment pas apporté de gros bénéfices à GitHub
  • La plupart des gens le savent, mais ce qui explique vraiment beaucoup de choses, c’est que GitHub appartient à Microsoft
    Et Microsoft a migré GitHub sur Azure
  • Je savais que c’était la propriété de GitHub, mais c’est la première fois que je vois directement des notes de release sur le blog GitHub plutôt que sur le blog npm

• Je me demande si la liste d’autorisation dans package.json est figée jusqu’à la version du paquet, ou si elle ne verrouille que le nom du paquet

• C’est bien que allowScripts soit désactivé par défaut
  [regarde sa montre] npm ne fait que rattraper pnpm avec 18 mois de retard ?

  • Maven en Java n’avait rien de ce genre, et je n’ai jamais eu l’impression que c’était nécessaire
    À quoi ça sert exactement côté JavaScript ?