De Node (fin de vie) à Node (LTS) et toutes les versions intermédiaires

Salut, Marco et Mateo, je suis vraiment ravi de vous avoir parmi nous.

Bonjour. C'est génial.

Avant de vous laisser vous présenter, permettez-moi de dire quelques mots sur moi. J'ai un lien avec vous tous grâce Node.js. Je crois que nous travaillons tous les trois pour des entreprises irlandaises qui utilisent Node.js. Voilà une petite anecdote intéressante.

Bon, tout d'abord, je m'appelle Javier Perez. Je suis responsable de la gestion technique des produits chez HeroDevs. Je m'occupe de plus de vingt-cinq technologies issues de l'écosystème JavaScript, ainsi que de quelques autres technologies en dehors de cet écosystème, sans oublier bien sûr Node.js.

Je disais que ce qui me lie à Mateo et Marco, c'est que — eh bien, cela semble déjà lointain, il y a environ douze ans — je travaillais pour une entreprise appelée FeedHenry, une société irlandaise basée à Waterford, en Irlande, et nous utilisions Node.js à l'époque où il en était encore à la version 0.7, je crois, puis 0.10, en 2012. Je me souviens de la version 0.10, puis de la 0.12. Nous avons traversé toutes ces étapes. Inutile de revenir sur l'histoire de la scission, puis de la réunification, et tout ça. C'est bien documenté.

Mais c'est à cette époque que j'ai travaillé en étroite collaboration avec Node.js. Nous développions des technologies RSS et des applications mobiles connectées à des services cloud — des opérations d'E/S très intensives, ce qui était tout nouveau à l'époque, mais nous savions que c'était la technologie qu'il nous fallait. Et je ne pense pas que nous ayons eu tort. Notre directeur technique et notre équipe d'ingénieurs n'ont pas eu tort.

La seule chose que j'ai à dire, c'est que je suis tout simplement ravi et honoré d'être ici avec vous, d'être aux côtés de ceux qui utilisent Node quotidien. Il s'est passé beaucoup de choses. Les choses changent tous les six mois, n'est-ce pas ? Et parfois de manière significative. C'est donc passionnant d'en parler. Sur ce, pourquoi ne pas commencer par toi, Mateo ? Pourrais-tu te présenter brièvement ? Raconte-nous ton parcours avec Node, OpenJS et TSC.

Bien sûr. Oui, bien sûr, bien sûr.

Bon, j'ai commencé à utiliser Node, je crois, en 2010, quelque chose comme ça. En 2011, j'ai commencé mon doctorat. Avant ça, je travaillais avec Ruby et Java, et je cherchais un langage aussi rapide que Java mais aussi facile à développer que Ruby. Ruby était très rapide pour le développement, mais très lent en exécution — du moins à l'époque. Je pense que c'est toujours le cas.

Et puis j'ai vu cette vidéo… et je me suis dit : « C'est ça, la technologie. » Mais pour être honnête, ce n'était pas le moment. Le moment décisif, c'est quand j'ai compris ce qu'était NPM et quand NPM a été lancé, ce qui n'a pas été immédiat — c'est arrivé quelque temps plus tard. Et quand j'ai réalisé — pour revenir à ce dont on parlait avec vous chez HeroDevs — que NPM allait essentiellement résoudre le problème de la réutilisation des logiciels à grande échelle, ce qui était un énorme problème pour le monde Java et même pour le monde Ruby avant ça. Personne n’avait trouvé comment faire ça avant NPM. C’est la principale invention de NPM, et le résultat a été le plus grand registre au monde — plein de bonnes choses mais aussi plein de logiciels malveillants, ce qui en fait la cible numéro un. C’est donc la cible la plus juteuse, et ainsi de suite.

J'ai eu la malchance d'être l'une des personnes visées par des acteurs étatiques qui cherchaient à accéder à mon ordinateur. Mais ça a été une expérience formidable. J'ai donc commencé à utiliser Node tôt, j'ai prédit l'affaire « left-pad » des mois avant qu'elle n'éclate, et je suis dans le feu de l'action depuis longtemps.

En fait, nous avons un petit passé commun. En 2013 et 2014, je travaillais pour une petite entreprise appelée NearForm, dont les bureaux se trouvaient juste à côté — littéralement juste à côté — de ceux de FeedHenry. Nous partageons donc ce petit bout d’histoire. Au fil des ans, quelques personnes sont passées de FeedHenry à NearForm et vice versa. Ça a été un parcours assez intéressant. Nous étions probablement en Irlande à la même époque, travaillant côte à côte. Ce furent des années agréables.

J'ai commencé à contribuer à Node.js après toute cette agitation. La scission avec IOJS a été un événement majeur, puis la fondation a vu le jour. Il y avait beaucoup de choses que je voulais corriger dans Node que je ne pouvais pas, et c'est après la création de la fondation que j'ai commencé à m'y atteler. J'ai commencé à contribuer un peu à Node, et au bout de quelques années, je suis devenu membre du CTC, qui a ensuite fusionné avec le TSC. Puis je me suis retrouvé — je ne sais pas trop comment — à tirer la courte paille et à être élu président du TSC Node.js.

On reparlera de TSC. On pourrait passer des heures rien qu'à parler de tout ce que tu as fait, Matteo. Et Pino et Fastify, alors ?

J'ai compris qu'au cours de l'année écoulée, tous les modules dont je m'occupe au sein de l'écosystème ont été téléchargés quarante-deux milliards de fois.

C'est dingue. Incroyable.

Et Fastify, comme son nom l'indique, c'est le framework le plus rapide, n'est-ce pas ?

Ouais. Peut-être.

Marco, parle-nous un peu de toi. Comment t'es-tu retrouvé impliqué dans Node TSC ?

Ouais, je ne fais vraiment pas partie des pionniers. J'ai commencé à m'intéresser à Node il y a Node huit ans. Avant ça, je travaillais avec Java, et je me disais toujours : « Je n'ai pas envie d'écrire tout ce code standard » — c'était ennuyeux. Et à l'époque, Node.js était la technologie la plus récente, encore à la pointe.

Ça fait un moment, et j'ai commencé à contribuer il y a quelques années, quand j'ai rejoint NearForm. Je crois que j'ai intégré l'équipe la semaine après le départ de Matteo. C'était donc une coïncidence. Puis je me suis davantage impliqué dans la sécurité de l'écosystème JavaScript et j'ai commencé à m'intéresser à toutes ces attaques qui avaient lieu.

C'est génial. Au fait, Marco n'a que vingt-deux ans, c'est ça ? Tu es très jeune, Marco.

Non, j'ai vingt-huit ans.

Vingt-huit ans. D'accord. C'est très jeune.

D'accord. Je voudrais vous parler de tout ce qui se passe autour de Node.js ces derniers temps. Mais avant cela — c'est d'ailleurs l'une des raisons pour lesquelles nous avons organisé cet événement avec OpenJS —, nous collaborons avec OpenJS depuis déjà quelques années. En fait, nous avons lancé il y a exactement deux ans le programme de pérennité de l'écosystème avec eux. Comme vous le savez, HeroDevs s'occupe des logiciels arrivés en fin de vie. Et OpenJS est très clair à ce sujet : nous voulons toujours plus d'innovation, plus de contributions, mais nous voulons aussi veiller à la sécurité et à la pérennité.

Nous le savons bien — et nous pourrions parler pendant des heures de la difficulté que rencontrent parfois les organisations ayant des déploiements à grande échelle pour simplement effectuer une mise à niveau ou migrer d’une version à une autre. Le risque de changements incompatibles et tout le reste. Mais nous venons tout juste d’assister à la fin de vie de Node . Le 30 avril, à la fin du mois d’avril, il y a moins d’un mois, Node — qui était une version très importante et largement utilisée — a atteint sa fin de vie. Fin de la maintenance, fin des mises à jour, des versions mineures et des correctifs.

Excuse-moi de t'interrompre, mais sais-tu combien de fois Node a été téléchargé en avril ?

Je ne vais pas aller sur npm tout de suite, mais dis-moi.

Quatre-vingt-quinze millions de fois.

C'est juste pour dire.

Je voulais juste souligner ici que la plupart des gens déploient Node.js dans une application, en particulier dans certains environnements, et qu’ils ne procèdent ensuite à aucune mise à jour. Ce que nous constatons à mesure que l'adoption se généralise, c'est que de nombreuses entreprises et équipes ne procèdent à aucune mise à jour. Et pour elles, mettre à jour Node un véritable défi, car elles ont généralement pris tellement de retard dans l'arborescence des dépendances qu'elles doivent procéder à une refonte et à une restructuration majeures pour mettre à jour l'intégralité de leur arborescence. Ainsi, au lieu de procéder par petites étapes, elles doivent effectuer une mise à jour radicale.

Mais c'est vrai, Node n'a pas dépassé la barre des 90 millions. Et en avril, pour être honnête, le mois où Node.js a enregistré le plus grand nombre de téléchargements s'élevait à environ 125 millions, en juin ou juillet de l'année dernière. Matteo dispose de nombreuses données intéressantes à ce sujet. J'ai vu certains de vos graphiques — ils sont vraiment excellents.

Oui, j'ai mes graphiques sur cet autre écran, donc je suis sûr de mes chiffres.

Marco, tu m'as montré une capture d'écran de toutes ces versions Node — tu as directement participé à la mise en ligne de la plupart d'entre elles. Raconte-nous cette expérience. Comment ça s'est passé ?

Je pense qu'environ 70 % des versions Node publiées lors du passage en LTS ont été réalisées par moi-même et d'autres bénévoles.

La publication Node beaucoup de travail et de patience, car il y a souvent des bugs, et cela implique de discuter avec de nombreuses personnes et de demander de l'aide sur des aspects que l'on ne maîtrise pas forcément. Et c'est vraiment beaucoup de travail. Je suis heureux que HeroDevs parraine mon travail open source sur les Node , car l'un des problèmes de pérennité est le financement des bénévoles pour effectuer ce type de travail fastidieux et parfois ennuyeux. Et je suppose que c'est aussi l'une des principales raisons pour lesquelles nous modifions le calendrier de publication.

Parlons-en. L'une des grandes nouvelles de la Node concerne la modification du calendrier de publication. Veux-tu commencer par là, Marco ? Quels ont été les éléments qui ont motivé cette décision ?

Bon, tout d'abord, pour ceux qui ne le savent pas encore : nous publions des versions tous les six mois. Les versions impaires ne sont pas des versions LTS. Ce sont les versions paires qui sont des versions LTS : les 18, les 20, les 22, et ainsi de suite. Mais cela va désormais changer pour passer à une version par an, et toutes les versions paires seront des versions LTS.

Et ce que j'apprécie aussi dans cette communauté, c'est que tout se passe vraiment au grand jour, n'est-ce pas ? Je suis allé chercher le forum de discussion où ce sujet avait été abordé il y a quelques mois.

Oui, la raison principale est que la gestion simultanée de quatre versions — car il arrive parfois qu’il y en ait quatre à publier — représente une charge de travail trop importante, surtout pour les versions de sécurité. Cela génère beaucoup de stress pour les contributeurs, qui sont pour la plupart bénévoles. L’autre problème est que la maintenance diverge trop. La version LTS est tellement différente de la dernière version qu'il est très difficile de rétroporter les correctifs. Cela représente donc une charge de travail considérable, qui pourrait s'avérer trop lourde pour être assumée par des bénévoles.

L'idée était donc la suivante : au lieu de multiplier les versions majeures accompagnées de changements importants, pourquoi ne pas essayer de réduire l'ampleur des versions que nous conservons ? Ainsi, en 2027, nous publierons Node , qui sera la première version impaire à devenir LTS. Cela signifie que nous n'aurons plus qu'une seule version majeure par an, ce qui simplifiera la vie des responsables des versions. Et je pense que cela aidera également les entreprises : il suffira de mettre à jour une seule version majeure au lieu de deux.

Tu as quelque chose à ajouter à ce sujet, Matteo ? Y a-t-il d'autres points qui ont été abordés ?

Au fait, ce qui est sympa, c'est que la version 27 coïncidera avec l'année, n'est-ce pas ? En 2028.

Le plus important, c'est de faire correspondre les années.

Node sera donc une version LTS, et Node , prévue pour 2027, le sera également. Il y a plusieurs éléments à prendre en compte. L'essentiel repose sur les données. Cette décision, plus que toute autre, s'appuie sur des données concrètes. Personne n'utilise les versions non LTS. Presque personne. Cela n'a donc aucun intérêt. Tout le travail que les responsables de publication effectuent pour les sortir ne profite qu'à très peu de gens. Et les auteurs de modules se retrouvent alors avec ces versions qu'il faut tester et maintenir, mais qui ne durent que six mois. Encore une fois, cela n'en vaut tout simplement pas la peine.

C'est un fait bien connu dans le monde de l'open source, quel que soit le projet : dès lors que la communauté s'engage officiellement à assurer un support à long terme (LTS), les utilisateurs en profitent. Pourquoi quelqu'un opterait-il pour une version non LTS ?

Oui, exactement. Certains le font parce qu'ils veulent tester de nouvelles fonctionnalités. Et vu la façon dont le nouveau programme est structuré, il y a une longue phase alpha pendant laquelle on peut intégrer des changements majeurs et des modifications qui brisent la compatibilité. Donc, si vous voulez être à la pointe, vous pouvez en profiter. Nous continuons à publier des versions alpha, donc le travail sera fait. Cependant, la principale différence est qu'avec ces versions alpha, il n'y aura aucune garantie de sécurité. Il n'y aura donc pas de rétroportage à effectuer, rien. Cela réduit la charge de travail nécessaire pour une version de sécurité, ce qui est l'une de nos principales préoccupations actuellement, compte tenu du flux considérable de rapports valides qui nous parviennent.

C'est l'autre point essentiel de cette discussion : la sécurité et les vulnérabilités. Avant d'aborder ce sujet, je pense qu'il y a un autre aspect important à souligner : tous les six mois, nous voyons apparaître de nombreuses nouvelles fonctionnalités. Il ne s'agit pas seulement de corriger les CVE, n'est-ce pas ? Je voudrais simplement vous demander : comment faites-vous ? Vous avez tellement de bénévoles, vous ajoutez constamment de nouvelles API, vous améliorez les performances...

Pour être honnête, analysons un peu tout ça. Est-ce qu’on améliore les performances ? Oui, peut-être un peu. Mais notre principale préoccupation est de ne pas rompre la compatibilité ascendante et de réduire au minimum les raisons qui empêchent les utilisateurs de passer à la nouvelle version. C’est ça, notre priorité. Comme je le dis toujours, on pourrait rendre Node.js nettement plus rapide, mais ça causerait des problèmes. Vous voulez aller plus vite ? Jusqu'où êtes-vous prêts à aller ? Voilà où nous en sommes. Et nous avons prouvé que même une compatibilité de quarante ou cinquante pour cent Node.js suffit à certaines personnes — il existe des projets qui fonctionnent ainsi, et ça marche très bien. Mais en réalité, les entreprises ayant des déploiements à grande échelle ne vont pas migrer. C'est difficile. C'est vraiment difficile.

Marco, quoi d'autre ?

J'ai encore une chose à dire. Les gens ne mettent pas à jour. À chaque nouvelle vague d'utilisateurs que nous gagnons, l'utilisation de Node , mais ils ne passent pas à la version suivante. Ça crée vraiment une stratification. J'ai vérifié, et il y a encore un nombre important de téléchargements de Node . Il est encore téléchargé environ vingt millions de fois par mois. Et on se dit : pourquoi les gens continuent-ils à tester avec ça ? C'est de l'histoire ancienne maintenant. C'est vraiment problématique.

En ce qui concerne les fonctionnalités, nous continuons à en proposer de nouvelles. Mais, dans une certaine mesure, nous restons en réalité très prudents. Nous aurions pu en proposer bien plus. Les gens voulaient en proposer bien plus, mais nous avons essayé de rester un peu plus modérés que ce qu’ils souhaitaient réellement.

Tu veux ajouter quelque chose, Marco ?

Je trouve ça incroyable, et je tire mon chapeau à tous les membres de la communauté Node.js, car ils ne cessent d’ajouter des fonctionnalités. En réalité, pour préserver la rétrocompatibilité et ne pas perturber les systèmes et frameworks existants en modifiant le code interne, nous essayons de ne pas causer de problèmes aux utilisateurs. C’est fou. Parfois, nous décidons de ne pas supprimer certaines choses car l’impact, même d’un simple changement majeur, pourrait toucher trop de personnes, trop de paquets. Le vrai problème, c’est l’écosystème. Par exemple, des paquets présents sur npm depuis quinze ans qui s’appuient sur des composants internes que nous voulons déprécier, mais nous ne pouvons pas le faire car le paquet n’est plus maintenu et enregistre cinquante millions de téléchargements par semaine. C’est pourquoi Node.js a tendance à être très conservateur. Nous pourrions déprécier beaucoup d’API, supprimer beaucoup de composants internes hérités qui ont été exposés, mais nous ne le pouvons pas. Ainsi, quand je consulte le journal des modifications d’une version majeure, je me dis toujours que nous aurions dû déprécier bien plus de choses, et que nous aurions pu faire bien plus, mais nous ne le pouvons pas.

Ce que j'entends confirme ce que je savais déjà de cette communauté et de ce projet : c'est un projet très bien géré. Vous faites un travail formidable, vous tous, bénévoles et collaborateurs. Vous faites preuve d'un engagement sans faille pour continuer à faire avancer les choses sans causer de problèmes, autant que possible. Chaque nouvelle version apporte son lot de changements majeurs et d'API obsolètes, mais il y a un engagement. Et c'est, à mon avis, la clé du succès de Node.js et la raison pour laquelle tant d'organisations et d'applications l'ont adopté : il y a un processus formel, et il y a un engagement envers un support à long terme.

Passons maintenant à… disons que ce n’est pas vraiment réjouissant, mais c’est un sujet intéressant et parfois même un peu triste : la sécurité. L’un des changements majeurs récemment annoncés par le TSC, Mateo, a été la suspension ou la mise en pause du programme de primes. Un article de blog l’expliquait, mais tu pourrais peut-être en dire quelques mots ici pour notre public — tout en précisant que cela ne change en rien le processus de correction des vulnérabilités.

Deux problèmes. Bon. Tout d’abord, depuis le début de l’année dernière, on a vu une quantité incroyable de « bricolages » basés sur l’IA utilisés pour signaler des vulnérabilités. Et ça a pris des proportions gigantesques. Il y a donc plusieurs réalités qui coexistent. Quand on signale une vulnérabilité dans Node.js, on peut tomber sur une faille qui touche tous les utilisateurs de Node peut, en substance, servir de « solution miracle » pour une attaque par déni de service. C’est vraiment grave. C’est l’un des cas de figure possibles. Ou bien on peut tomber sur une vulnérabilité qui, techniquement, en est une, mais qui dépend de l'environnement — il faudrait que la Lune et Vénus soient alignées, et la seule façon de la déclencher serait de sauter trois fois du pied droit, puis trois fois du pied gauche, et de prononcer les mots magiques. C'est le genre de choses qui sont signalées.

Pour être honnête, ce sont de véritables vulnérabilités. Je ne dis pas qu'elles n'en sont pas. Je dis simplement qu'il s'agit au mieux de petits détails qui, dans une chaîne plus longue, pourraient être exploités pour permettre à un attaquant d'aller plus loin, mais qui, pris isolément, ont très peu d'importance. Ce sont toutefois des CVE, nous devons donc les traiter comme tels. Mais le coût de leur détection dans une base de code est quasi nul.

La question qui se pose alors est la suivante : devrions-nous leur offrir une prime ? Devrions-nous payer pour cela ? Je dépense des jetons pour en générer d'autres et gagner de l'argent. Disons-le ainsi : dépenser cent euros en jetons pour obtenir quelque chose qui rapporte mille euros en prime, c'est un excellent investissement. Un abonnement de cent dollars se transforme en mille euros par mois grâce aux primes. On peut vivre de cela.

Mais est-ce vraiment quelque chose que nous voulons encourager ou soutenir ? Si des entreprises sont prêtes à le financer, bien sûr. Nous sommes tout à fait disposés à trier les demandes et à faire le travail. Mais la réalité, c’est qu’il n’y avait plus de sponsor. Et pour être honnête, nous voulions mettre fin à ce n’importe quoi. Ce n’importe quoi était le plus gros problème, car beaucoup de gens y voyaient un moyen de gagner de l’argent rapidement, sans aucune compétence en matière de rédaction de rapports. Ça ne me dérange pas de discuter avec une IA, mais celle-ci est plus compétente que bon nombre de ce que nous avons vu. Nous avons littéralement vu des copies-collés de la consigne collés à l’intérieur d’un rapport. La compétence ne résidait même pas dans la capacité à copier-coller correctement.

Nous voulons bien sûr parler de l'IA. Le public veut parler de l'IA. Mais avant tout, Marco, il y a un autre point important : la suspension du programme de primes ne modifie en rien le processus de signalement des failles de sécurité. Celui-ci reste inchangé.

Pourriez-vous nous expliquer ce processus ? L'accueil, le triage ?

Oui, les signalements se font via HackerOne. Nous recevons des rapports sur HackerOne. Nous effectuons un triage de ces rapports — c'est une activité bénévole, donc certaines personnes s'en chargent quand elles ont le temps. Peu de gens sont intéressés par ce travail car nous recevons énormément de rapports, et il existe actuellement un déséquilibre entre le temps nécessaire pour générer un rapport et celui nécessaire pour le trier. Il faut du temps pour vérifier la véracité d'un rapport et pour le reproduire. C'est l'un des plus gros problèmes.

Mais une fois que nous avons reçu le rapport sur HackerOne et que nous disposons d'un nombre suffisant de signalements pour publier une mise à jour, nous annonçons, par exemple, que nous publierons une mise à jour de sécurité dans deux semaines. En interne, nous développons le correctif pour ces vulnérabilités. Et nous devons coordonner plusieurs versions pour qu’elles soient publiées en même temps que la version mise à jour. C’est la partie la plus difficile, car il faut coordonner deux ou trois personnes — parfois même plus —, car nous voulons réunir les personnes qui corrigent les vulnérabilités et celles qui s’occupent de la publication pour qu’elles travaillent en même temps. Ainsi, lorsqu’il y a une mise à jour de sécurité, cela représente beaucoup de travail. Ces quelques semaines sont très intenses pour toutes les personnes impliquées.

Et c'est l'une des raisons pour lesquelles nous avons modifié le calendrier : pour réduire la charge de travail pendant ces périodes. Et bien sûr, cela va sans dire : plus le rapport contient d'informations, mieux c'est. Si vous avez déjà une proposition de solution, n'hésitez pas à l'inclure dans votre rapport.

C'est extrêmement rare que les gens fournissent une solution. La plupart du temps, c'est impossible. La plupart des gens, même s'il y a une solution, n'en fournissent pas. Mais nous les acceptons volontiers. Parfois, il y a de très bons correctifs. Parfois, il n'y en a pas.

Le processus fonctionne, mais il est très intense, notamment parce qu’il s’agit d’une chaîne de tâches. Nous gérons quelques dépendances de Node au sein Node l’organisation Node.js. Notamment une bibliothèque appelée LLHTTP, qui est notre analyseur HTTP. Nous devons publier des versions de cet analyseur HTTP — d’ailleurs, c’est une technologie intéressante, vous devriez demander à Paolo d’en parler un de ces jours. Bref, il y a l'analyseur HTTP. Ensuite, nous avons Undici, la bibliothèque que nous utilisons pour Fetch, ainsi que de nombreuses nouvelles API basées sur WhatWG. Je suis le principal responsable de la maintenance d’Undici, et à chaque version de sécurité de Node, une série de correctifs Undici est intégrée. Actuellement, Node trois versions LTS — Node , Node et la version active, Node — et nous devons publier des correctifs pour les trois. Node utilise Undici 6, et les autres versions ont leur propre version.

C'est un travail colossal que cette communauté, ces contributeurs et ces collaborateurs accomplissent. Et puis, il y a des milliers et des milliers d'organisations qui exploitent des systèmes de production en direct en utilisant JavaScript, Node.js, TypeScript, etc. C'est pourquoi des entreprises comme HeroDevs s'engagent en retour et apportent leur contribution à ces communautés. Non seulement vous apportez votre aide, mais vous acquérez également une grande expertise et une riche expérience en faisant partie de ces communautés.

Bon, parlons de l'IA, parce que bien sûr, tout le monde veut parler de l'IA. Il existe une multitude de nouveaux outils et les gens signalent des vulnérabilités liées à cette IA. Mais j'ai aussi entendu dire, et Marco, tu as écrit un excellent article de blog à ce sujet, qu'il ne s'agit pas seulement de signaler les problèmes : le contexte et les connaissances sont les éléments les plus importants. Mais je veux aussi souligner le fait que la situation s'améliore réellement. Peut-être que maintenant, ces modèles de langage (LLM) signalent de véritables vulnérabilités.

C'est vrai. C'est vrai. On a de vraies vulnérabilités. C'est bien réel. Les capacités des grands modèles de langage (LLM) — la plupart ne sont encore que des bugs, mais maintenant, il s'agit même de véritables vulnérabilités. Je pense que le taux a considérablement augmenté. La dernière fois que j'ai vérifié, je crois que c'était 66 % contre 50 % auparavant. À un moment donné, c'était vraiment grave, mais la situation s'est ensuite améliorée. Jusqu'à présent, je dirais que la plupart des problèmes signalés sont suffisamment plausibles et ne sont pas insignifiants à déboguer. Les problèmes insignifiants ont été documentés. Nous menons une campagne visant à documenter dans le MD de sécurité tout ce qui distingue une bonne vulnérabilité d'une mauvaise.

Node.js est-il lié à Mitre ?

Malheureusement, ce n'est pas le cas. Nous avons demandé à y avoir accès, mais cela ne nous a pas encore été accordé. Je suis sûr que cela finira par arriver — c'est forcément l'un des projets open source phares. Quoi qu'il en soit, même sans cela, nous constatons une amélioration au niveau des problèmes signalés par les grands modèles de langage (LLM). Et ce que j'ai lu de très intéressant, c'est qu'au-delà des capacités humaines, ils peuvent enchaîner plusieurs vulnérabilités et créer un exploit concret.

Oui, c'est là que réside toute la difficulté. C'est ça, la particularité : ce petit détail précis. Dans certains cas, des vulnérabilités (CVE) qui, prises isolément, ne présentent qu'un niveau de gravité faible ou moyen peuvent, lorsqu'elles sont combinées à d'autres, devenir extrêmement critiques.

Marco, j’ai une question à te poser : on reçoit donc de nouveaux CVE et de nouveaux correctifs pour les failles de sécurité. Mais ensuite, il faut revenir en arrière et appliquer ces correctifs aux versions en fin de vie pour HeroDevs. Qu’est-ce que cela implique exactement ?

Ouais, donc… quand je dis que je travaille sur Node , Node , Node , les autres collaborateurs me regardent d’un air perplexe. Travailler sur d’anciennes versions de Node assez difficile à cause des dépendances très anciennes. L’autre gros problème, c’est le manque de sécurité de ces anciennes versions. Ça arrive souvent. Et pendant que je corrige ces failles, je me demande : comment avons-nous survécu avec ça il y a six ou sept ans ? Parce qu’au fur et à mesure que nous avons évolué, nous avons découvert beaucoup de failles, beaucoup de bugs. À chaque nouvelle mise à jour de sécurité, je vérifie toujours si elle s’applique aux versions en fin de vie, et la plupart du temps, c’est le cas. Donc, même en avançant, nous continuons à trouver des bugs dans les anciennes versions. C’est dingue.

Pour que ce soit bien clair pour l'auditoire : la fin du support à long terme signifie qu'il n'y aura plus de correctifs en amont. Pour Node , par exemple, vous devrez vous tourner vers une offre commerciale comme HeroDevs. C'est évidemment un défi de taille, et il est tout à fait logique qu'un projet continue d'évoluer — et, franchement, qu'il évolue aussi vite que possible. Ce qui, bien sûr, pose le défi de la migration et des changements incompatibles. Et comme Matteo le disait tout à l'heure, nous constatons que les entreprises et les organisations ne migrent pas nécessairement. Elles continuent d'utiliser des versions comme la 18, la 20 et certaines plus anciennes.

C'est un travail colossal, Marco, et toi ainsi que certains autres ingénieurs ici chez HeroDevs y avez consacré beaucoup d'efforts, tant pour le développement que pour les tests. D'ailleurs, c'est justement une autre question que je voulais vous poser. Chaque nouvelle version doit nécessiter une quantité incroyable de tests. Comment faites-vous ?

Oui. Le plus difficile dans la mise en production, c'est d'obtenir le feu vert de l'intégration continue (CI). Nous avons énormément de tests à effectuer sur une multitude de plateformes peu courantes. Dans Goldmine, nous utilisons un système appelé « Canary » qui nous permet de tester la version candidate avec les paquets npm de l'écosystème afin de nous assurer qu'elle ne provoque pas de dysfonctionnements. Nous avons tellement de tâches CI qui prennent des heures. Chaque fois qu'une tâche échoue, il faut la relancer et attendre plusieurs heures. C'est donc assez pénible, mais c'est important.

Ça ne passe jamais.

Ça ne s'arrête jamais. À un moment donné, j'essayais vraiment d'améliorer la fiabilité. On reçoit chaque jour un rapport de fiabilité qui indique le nombre de tests instables, et pendant un certain temps, je me suis mis à corriger ces tests et à intégrer ces données dans l'IA. Quelques personnes se sont plaintes que les PR n'étaient pas terribles, mais au moins, j'essayais d'apporter mon aide. Puis j'ai arrêté. Mais le problème est très délicat, car même intégrer ces corrections est difficile. Ce n'est pas simple.

Oui, c'est un travail colossal. Tous les développeurs qui s'occupent de la publication de versions savent de quoi je parle.

Je voudrais terminer par une dernière remarque. Une réunion a récemment eu lieu à Londres, où la communauté Node.js s'est retrouvée. Plusieurs initiatives y ont été abordées. C'est à cette occasion que ce changement de calendrier de publication a été annoncé. Avez-vous quelque chose à ajouter, Marco ou Matteo, concernant l'avenir de Node.js ? En matière de sécurité, par exemple : y a-t-il d'autres nouvelles ou changements concernant la manière de gérer cette augmentation du nombre de rapports CVE ?

Je siège également au conseil d'administration de la Fondation OpenJS, et nous travaillons actuellement avec un groupe de fournisseurs qui ont proposé de financer le développement du programme de primes. Nous cherchons à mettre en place une structure qui leur permette de soutenir le programme et d'en tirer un bénéfice, tout en justifiant le temps consacré par les responsables de la maintenance. Si nous offrons une prime pour quelque chose de relativement facile à obtenir, cela revient littéralement à un moyen de s'enrichir rapidement. Cela ne devrait probablement concerner que les vulnérabilités graves et critiques.

Pour être honnête, on pourrait tout simplement se dire : prenons cette montagne d’argent et dépensons-la pour trouver nous-mêmes toutes les failles. C’est devenu un jeu de chiffres. J'aimerais vraiment offrir de grosses primes aux chercheurs qui font un travail concret et solide et qui trouvent des failles réelles pouvant avoir un impact sur des millions de personnes. Et nous en avons eu quelques-unes — certaines très, très importantes. Mais en général, il s'agit de cas marginaux, ou peut-être que cela ne fonctionne que si vous ne placez pas votre node derrière un CDN et un équilibreur de charge, ce qui n'est franchement le cas de personne à l'heure actuelle.

Ou alors, quelqu'un n'arrête pas de signaler le problème lié au protocole de l'inspecteur. Nous l'avons écrit partout : si vous utilisez le protocole Inspector, vous êtes seul responsable. Ce sont des outils de débogage destinés au développement. Ne les laissez pas ouverts dans un système de production. Et les gens continuent de le signaler comme un scénario d'attaque. Mais littéralement, vous ne pouvez pas sécuriser ce protocole. Il n'y a aucun moyen de le sécuriser — il est littéralement conçu pour permettre à quelqu'un de prendre le contrôle de cette node . C'est impossible.

Quand je travaillais davantage dans le domaine de la sécurité des applications, j'avais l'habitude de faire une présentation où je disais : « Écoutez, il existe des millions de failles de sécurité. Concentrez-vous davantage sur les exploits répertoriés. » Mais même ceux-là sont souvent insignifiants.

Parlons d'une vulnérabilité que j'ai traitée lors de la dernière session sur la sécurité — dans Undici. Dans Node.js, nous fournissons une implémentation WebSocket conforme à la spécification. Ce n'est pas une norme idéale, mais c'est un autre sujet. Quoi qu'il en soit, la norme WebSocket offre la possibilité de compresser les paquets, car les paquets WebSocket ont leur propre trame par-dessus TCP — c'est HTTP, WebSocket, puis leur propre trame par-dessus. Et vous pouvez compresser ces paquets. Je ne le savais pas, mais nous prenons cela en charge.

Et il s'avère que si quelqu'un utilise Node.js pour se connecter à une instance WebSocket distante à laquelle vous ne faites pas confiance, pour quelque raison que ce soit, ce serveur peut vous envoyer un paquet « silver bullet » qui provoque un déni de service et plante votre application — car il s'agit, disons, d'une centaine de kilo-octets qui se gonflent jusqu'à atteindre une centaine de gigaoctets en mémoire, et votre application plante. Un jeu d'enfant.

Voilà donc pour cela. Et l'autre aspect de la question — toujours en parlant d'Undici —, c'est qu'il s'agit d'une fonctionnalité qu'il faut activer explicitement. Cette vulnérabilité n'apparaît que si vous activez une fonctionnalité expérimentale et écrivez du code qui la met en œuvre manuellement. On se retrouve donc face à un spectre : d'un côté, elle est difficile à exploiter. Il faut une application qui se connecte à un WebSocket acceptant un serveur WebSocket distant en entrée, ce qui en limite considérablement la portée.

Tant, tant de détails. C'est cela qui, pour moi, fait toute la valeur que ce projet et tous les bénévoles apportent à cet écosystème.

Je viens de parcourir rapidement les questions. Je pense que nous les avons toutes abordées. Il y avait une question sur le type de vulnérabilités liées à l'IA. Je voudrais juste conclure en disant : le temps passe vite quand on s'amuse. Je suis sûr que nous pourrions encore discuter de ce sujet pendant deux ou trois heures.

J'espère que cela a été utile pour le public. Nous allons continuer à organiser des webinaires de ce type. Permettez-moi de rappeler que HeroDevs est l'un des membres fondateurs du programme « Ecosystem Sustainability » de la Fondation OpenJS. Nous soutenons la communauté open source tout en proposant nos services aux organisations qui utilisent encore des versions de Node arrivées en fin de vie. Nous assurons la prise en charge à partir de la version 12 — Marco, c'est bien ça ?

Douze, quatorze, seize, dix-huit, et maintenant vingt.

Nous proposons également des versions personnalisées des versions 22 et 24 avant leur fin de vie, pour les clients qui souhaitent s'y préparer avant la date de fin de vie.

Parfait. Eh bien, merci beaucoup, Matteo et Marco, d'avoir été des nôtres. J'apprécie que vous ayez pris le temps de nous rejoindre. J'aimerais beaucoup poursuivre cette discussion, et merci à tous de nous avoir suivis. Au revoir à tous. Au revoir.

‍