Comment faire un package npm pour récupérer des cartes de crédit : hackernoon.com/im-harves… (anglais)
Lundi 08 janvier 2018 à 08:36
L'odyssée des Champignons !!!
—
A-lex
Discussions
Billet - Comment faire un package npm pour récupérer des ...
Cette discussion est en relation avec le billet suivant :
yaugun tas de problèmes si :Oui mais non, semver est un outil puissant pour palier à ça, le développeur est responsable de la plage de versions compatibles avec son application.
- tu n'as pas ancré les versions à un moment donnée, ça risque de te péter pas mal de truc lors d'un update
- si tu as ancré tes versions à instant T, au final ça te prend un long moment de mise à jour
yaug- les cascades de dépendances c'est un horreur, et pas que en terme de sécurité.Là, oui
Je plussoie Fabe sur l'usage de semver. Si les paquets dont tu dépends le respecte, c'est du bonheur pour limiter la casse (aussi bien pour bénéficier des fixes automatiquement, mais aussi pour éviter les changements incompatibles). Dans tous les cas, la mise à jour des dépendances est quelque chose à faire avec parcimonie.
Pour Lexpage, les contraintes fixent une version explicitement (de sorte à pouvoir reproduire l'environnement de prod à l'identique), mais pour la plupart de mes autres projets (publics ou pas), les contraintes sont plus souples, et j'utilise l'intégration continue pour vérifier que mes tests passent toujours avec des versions plus récentes des dépendances. L'avantage, c'est qu'en ayant des contraintes souples, tu limites les soucis de co-installabilité dans la plupart des packages managers (sauf si, comme npm, c'est déjà pris en compte "nativement", ou si tu fais usage d'environnements virtuels).
C'est une problématique qu'on a considéré (et qu'on considère encore) dans nos études des écosystèmes logiciels. On a notamment été surpris de la quantité de liens de dépendances dans certains écosystèmes (par ex, la profondeur médiane de l'arbre de dépendances des paquets périphériques dans Cargo est de 6 !! Vas-y pour vérifier tout ça à la main
), ou encore l'importance de certains paquets (on a identifié plusieurs centaines de paquets sur npm qui étaient requis, directement ou transitivement, par plus de 5% de tout le système, c'est-à-dire par plus de 20.000 autres paquets ! Oui oui, ça vous rappelle left-pad, c'est normal ). Si ça vous intéresse, le papier (une trentaine de pages) va bientôt être publiés chez Springer (mais je peux vous envoyer la version pré-print en privé).
Vu que cette "abondance" de dépendances augmente fameusement le risque de propager des problèmes (par ex, un changement incompatible upstream, qui casse le paquet dépendant, cassant lui-même ceux qui en dépendent et ainsi de suite), on s'est focalisé récemment sur les vulnérabilités des paquets npm. A partir d'une simple liste de 400 vulnérabilités (concernant un peu moins de 300 paquets différents sur npm), on obtient plus de 70.000 autres paquets vulnérables *au premier niveau de dépendances* (l'évaluation des contraintes de dépendances sur l'ensemble des versions disponibles prend trop de temps pour qu'on fasse ça transitivement, au moins pour l'instant). Oui, un bon gros sixième de tous les paquets npm ont été vulnérables à un moment ou à un autre à cause d'une de ces 400 vulnérabilités !
Pire : si ces vulnérabilités sont typiquement corrigées rapidement en upstream (il faut parfois 2 ans pour que la vulnérabilité soit découverte, mais la correction se fait en quelques mois généralement), on a pu constater que ce n'était pas le cas systématiquement dans les paquets qui en dépendent. Un peu moins de 50% des paquets dépendants sont corrigés "automatiquement" (parce que la contrainte autorise la release contenant le fixe), et sur les 50% restants, c'est variable : soit le paquet dépendant n'est pas à jour depuis un moment (même s'il est encore fortement téléchargé !) et donc est toujours vulnérable, soit il a été mis à jour mais sans pour autant modifier la contrainte permettant d'autoriser le fix (soit par ignorance de la vulnérabilité/fix, soit par précaution vis à vis d'un changement incompatible). Et pour ceux qui sont corrigés (mais pas automatiquement), on a mesuré que ça prenait beaaaaaucoup plus de temps (de mémoire, la probabilité que ça soit fixé dans les deux ans est de 50/50 seulement !). Bref, on a été surpris (même si on s'attendait à ce que les chiffres montrent tout ça, dans une moindre mesure) et on se dit que finalement, c'est pas le paquet "initialement vulnérable" qui est vraiment en cause, mais bien tous les échelons intermédiaires... (le papier est presque finalisé, je pourrai bientôt l'envoyer si certains le souhaitent).
Vu ces résultats, on a commencé à bosser sur le "technical lag" (c'est à dire le retard technique qu'un paquet peut avoir parce qu'il limite explicitement ou implicitement les versions installables de ses dépendances). Les calculs sont déjà faits (mais pas les analyses), j'espère que ça va donner de bons résultats (on s'attend à un retard technique important, que ça soit en terme de temps passé sans profiter de la mise à jour d'une dépendance, ou encore en terme de "distance de versions" (le nombre de majeurs/mineurs/patchs "ratés").
Pour Lexpage, les contraintes fixent une version explicitement (de sorte à pouvoir reproduire l'environnement de prod à l'identique), mais pour la plupart de mes autres projets (publics ou pas), les contraintes sont plus souples, et j'utilise l'intégration continue pour vérifier que mes tests passent toujours avec des versions plus récentes des dépendances. L'avantage, c'est qu'en ayant des contraintes souples, tu limites les soucis de co-installabilité dans la plupart des packages managers (sauf si, comme npm, c'est déjà pris en compte "nativement", ou si tu fais usage d'environnements virtuels).
C'est une problématique qu'on a considéré (et qu'on considère encore) dans nos études des écosystèmes logiciels. On a notamment été surpris de la quantité de liens de dépendances dans certains écosystèmes (par ex, la profondeur médiane de l'arbre de dépendances des paquets périphériques dans Cargo est de 6 !! Vas-y pour vérifier tout ça à la main
), ou encore l'importance de certains paquets (on a identifié plusieurs centaines de paquets sur npm qui étaient requis, directement ou transitivement, par plus de 5% de tout le système, c'est-à-dire par plus de 20.000 autres paquets ! Oui oui, ça vous rappelle left-pad, c'est normal ). Si ça vous intéresse, le papier (une trentaine de pages) va bientôt être publiés chez Springer (mais je peux vous envoyer la version pré-print en privé). Vu que cette "abondance" de dépendances augmente fameusement le risque de propager des problèmes (par ex, un changement incompatible upstream, qui casse le paquet dépendant, cassant lui-même ceux qui en dépendent et ainsi de suite), on s'est focalisé récemment sur les vulnérabilités des paquets npm. A partir d'une simple liste de 400 vulnérabilités (concernant un peu moins de 300 paquets différents sur npm), on obtient plus de 70.000 autres paquets vulnérables *au premier niveau de dépendances* (l'évaluation des contraintes de dépendances sur l'ensemble des versions disponibles prend trop de temps pour qu'on fasse ça transitivement, au moins pour l'instant). Oui, un bon gros sixième de tous les paquets npm ont été vulnérables à un moment ou à un autre à cause d'une de ces 400 vulnérabilités !
Pire : si ces vulnérabilités sont typiquement corrigées rapidement en upstream (il faut parfois 2 ans pour que la vulnérabilité soit découverte, mais la correction se fait en quelques mois généralement), on a pu constater que ce n'était pas le cas systématiquement dans les paquets qui en dépendent. Un peu moins de 50% des paquets dépendants sont corrigés "automatiquement" (parce que la contrainte autorise la release contenant le fixe), et sur les 50% restants, c'est variable : soit le paquet dépendant n'est pas à jour depuis un moment (même s'il est encore fortement téléchargé !) et donc est toujours vulnérable, soit il a été mis à jour mais sans pour autant modifier la contrainte permettant d'autoriser le fix (soit par ignorance de la vulnérabilité/fix, soit par précaution vis à vis d'un changement incompatible). Et pour ceux qui sont corrigés (mais pas automatiquement), on a mesuré que ça prenait beaaaaaucoup plus de temps (de mémoire, la probabilité que ça soit fixé dans les deux ans est de 50/50 seulement !). Bref, on a été surpris (même si on s'attendait à ce que les chiffres montrent tout ça, dans une moindre mesure) et on se dit que finalement, c'est pas le paquet "initialement vulnérable" qui est vraiment en cause, mais bien tous les échelons intermédiaires... (le papier est presque finalisé, je pourrai bientôt l'envoyer si certains le souhaitent).
Vu ces résultats, on a commencé à bosser sur le "technical lag" (c'est à dire le retard technique qu'un paquet peut avoir parce qu'il limite explicitement ou implicitement les versions installables de ses dépendances). Les calculs sont déjà faits (mais pas les analyses), j'espère que ça va donner de bons résultats (on s'attend à un retard technique important, que ça soit en terme de temps passé sans profiter de la mise à jour d'une dépendance, ou encore en terme de "distance de versions" (le nombre de majeurs/mineurs/patchs "ratés").
yaugVu qu'on doit indexer Springer bientôt au boulot, j'aurais peut être enfin tes publications sous la main.La majeure partie de mes publications sont chez ACM ou IEEE
Vous allez indexer la partie payante aussi de Springer, quelque soit le domaine, ou vous vous limitez à ce qui est publiquement disponible ?
Si ça peut t'aider, je suis aussi publié dans Lecture Notes in Computer Science, RAIRO ITA (Theoretical Informatics and Applications), et CEUR (moins "officiel"). Mais c'est surtout chez IEEE que sont mes publis, et un peu chez ACM (ce sont les "classiques" pour les proceedings de conférence, les (chapitres de) livres ou les journaux). Ah oui, et d'ici quelques jours/semaines, je serai aussi chez Springer
