Npm et dépendance Nodejs : sûr ?

Tu as complètement raison dans ton raisonnement, quand tu inclus un module tu dois accorder ta confiance à celui-ci car il peut bien faire ce qu’il veut.

En accordant ta confiance à un module tu dois également accorder ta confiance à tous les modules dont le module que tu inclus à accordé sa confiance et ainsi de suite…

Les risques sont donc bien concrets, et peut-être même que la NSA à volontairement affaiblis des packages en ayant contribuer à certain pour plus facilement intercepter des communications qui sais.

Mais j’ai une question, une fois que vous mettez un projet en prod sa vous arrive fréquemment de faire des npm update ?

De plus les tests ne sont-ils justement pas censé mettre en évidence des comportements qui auraient été cassé ? Tant au niveau des packages inclus qu’au niveau de l’application développée, si un package commence à faire n’importe quoi, à priori cela aura un impact sur l’application finale et des tests devraient foirer non ?

Mais j’ai une question, une fois que vous mettez un projet en prod sa vous arrive fréquemment de faire des npm update ?

J’espère…

De plus les tests ne sont-ils justement pas censé mettre en évidence des comportements qui auraient été cassé ?

Les tests couvrent ce qu’ont leur demande de couvrir. Tant que certains cas/bug n’ont pas été testé, il peut s’avérer difficile de les envisager (et donc laisser des portes ouvertes)

Je réfléchissais à la conception de Nodejs et de ses dépendances. Par exemple, si j’ai besoin d’un module nodejs (comme expressjs ou sockjs) je vais sur github/site npm, je regarde ce qui me plait, puis j’installe le package via npm install <package> qui va le télécharger à partir de nodejs (C’est bien ça ?). Mais ces librairies ont souvent des dépendances, qui elles aussi ont des dépendances. Pour seul but de s’épargner 30-40 lignes de code. On peut vite se retrouver avec 122 modules node pour une seule librairie. Donc potentiellement une centaine de comptes github différents et donc d’accès possible.

A part le nombre de dépendances, principalement du fait que JS n’a pas de lib standard, c’est pareil pour tous les packages managers de tous les langages.

J’avais lu qu’un développeur avait enlevé ses packages de npm et ça avait causé pas mal de soucis, avant qu’un autre développeur remette une copie qu’il avait, pour corriger ce problème. Donc dans cette hypothèse les développeurs/comptes github owner sont libres de modifier les releases mises en ligne pour ajouter une modification non voulue.

C’est faux. Tu ne peux dépublier un paquet (resp. une version d’un paquet) que jusqu’à 24h après sa publication. Tu ne peux dans aucun cas modifier une version publiée.

Je me trompe quelques parts ? Les risques sont-ils quasi nuls ou dois-je m’inquiéter ?

Les risques sont les mêmes que n’importe où ailleurs. Tout package manager permet des dépendances transitives. Vérifier tous les changelogs de toutes les modifications de toutes tes dépendances transitives est impossible. Déjà parce qu’il n’y a pas toujours de changelog, ensuite parce qu’il y a trop de dépendances transitives.

Même avec ZdS, qui est du python, on a le problème que tu décris. Le mieux que tu puisses faire c’est respecter semver et espérer que les packets dont tu dépends respectent eux aussi semver. Si tout le monde le fait, ça limite grandement le problème.

C’est faux. Tu ne peux dépublier un paquet (resp. une version d’un paquet) que jusqu’à 24h après sa publication.

Pour la petite histoire, tu ne peux plus, mais on pouvait effectivement avant. (voir la partie What happens next).

Oui, à cause du fiasco left-pad, absolument.

J’ai pas raconté l’histoire mais j’aurais peut-être dû. Je voulais surtout dire : c’est faux. A l’heure actuelle, c’est faux, et donc avoir peur que quelqu’un dépublie une dépendance que t’utilises, c’est une crainte infondée.