Posté par Jean Gabes (site web personnel) .
Évalué à 4 (+2/-0).
Dernière modification le 06 novembre 2024 à 11:12.
Suite de la série à succès "Faut pas charger du code sans faire attention".
Bon après faut avouer que garder la main sur toute la supply chaine avec la tonne de dépendances pour le moindre framework aujourd'hui, c'est un métier à temps pleins.
Qui aurait pu deviner qu'un dépôt centralisé que tout le monde utilise, y compris des acteurs privés, qui permet à tout le monde d'y publier du code, sans aucune restriction, aucune validation, aucune revue, aucune limite, contiendrait du malware ?
On parle de NPM, mais PyPI, crates.io, CPAN, etc… ont tous le même problème.
Et même quand tu as de la revue/validation/limitation comme les dépôts officiels d'une distribution Linux, on n'est pas à l'abri.
D'un point de vue "expérience développeur", cet outillage est très pratique. Mais d'un point de vue "sécurité", je rejoins de plus en plus l'avis de Drew Devault et sa décision de ne pas supporter ça pour son langage Hare.
Je ne suis pas sûr que devoir aller vérifier quelle version de telle librairie disponible sur github et mise à la main dans le projet doit beaucoup plus efficace en terme de sécurité…
Je ne suis pas sûr que devoir aller vérifier quelle version de telle librairie disponible sur github et mise à la main dans le projet doit beaucoup plus efficace en terme de sécurité…
tu en parleras à ceux qui ont pété leur CI/CD avec is-even() :-)
disposer localement de l'intégralité de ses dépendances garantit 2-3 choses et est une bonne pratique :
continuité de la CI/CD même si les sources deviennent indisponibles (la base mais tout le monde n'a pas l'air de s'en rendre compte o_O)
capacité à savoir quelle version exacte est utilisée
possibilité de patcher à la volée avant de recompiler (genre boucher une faille faisant l'objet d'une CVE… à défaut de trouver des 0day)
recensement effectif des versions utilisables de ce qui est utilisé (bon ça rajoute du boulot pour les actualiser, mais ça s'automatise au besoin)
j'en passe et des meilleurs…
normalement, il ne devrait pas y avoir besoin d'en remettre une tartine :/
Tout ce que tu dis est faisable tout en utilisant un gestionnaire de dépendance avancé et plus ou moins centralisé, pour peu que tu utilise un repo d’artefacts dans ton infra. C’est ce qui se fait couramment depuis longtemps dans le monde java avec artifactory, et plus récemment avec ce que propose gitlab.
Mettre tes dépendances en dur dans ton repo git ne solutionne en rien les gens qui mettent n’importe quelle depedance dans leur soft, mais complique beaucoup leur suivi. En pratique, plus ton process d’update de tes dépendances est manuel, moins leur mise à jour est effectuée régulièrement. Sans parler du suivi de leur recensement.
Pour moi, le problème de base, c’est surtout le nombre énorme de dépendances triviales qui sont dans ces repos qui rendent impossible leur suivi effectif, surtout si tu rajoutes de la transitivité et les versions multiples que ca ramène. Et aussi, les pratiques qui consistent à ne pas se soucier des dépendances qu’on importe.
Et là éventuellement, il y a un avantage pour la gestion à la main : c’est tellement chiant et impactant que tu va pas être tenté de mettre un truc pour trois lignes. Maintenir le code sera largemet moins coûteux… mais c’est aussi le cas pour ceux qui ont importé is-even.
Je dirais bien que normalement on ne devrait pas avoir à en faire des tartines, mais je me retiendrai par respect pour mon interlocuteur.
tu ne parles pas de la même chose : j'oppose récupérer dynamiquement à gérer en local (ce que les outils que tu pointes font quasi bien), non artifactory n'est pas la solution, au mieux une solution, c'est plus une question de compréhension
Mettre tes dépendances en dur dans ton repo git ne solutionne en rien les gens qui mettent n’importe quelle dependance dans leur soft, mais complique beaucoup leur suivi.
ce n'est pas ce que j'indiquais (et justement une des limites que je pointe si personne ne regarde… j'ai failli dire gère mais j'y crois peu :/
Et aussi, les pratiques qui consistent à ne pas se soucier des dépendances qu’on importe.
oui bah ça, tu prends un développeur pour taper sur l'autre et tu vas prendre un café…
Maintenir le code sera largement moins coûteux… mais c’est aussi le cas pour ceux qui ont importé is-even.
yep :/ peu le font effectivement, déjà que comprendre qu'ils peuvent le patcher voire remonter un bug upstream leur est une grande inconnue o_O
# Episode 354
Posté par Jean Gabes (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 06 novembre 2024 à 11:12.
Suite de la série à succès "Faut pas charger du code sans faire attention".
Bon après faut avouer que garder la main sur toute la supply chaine avec la tonne de dépendances pour le moindre framework aujourd'hui, c'est un métier à temps pleins.
# Qui aurait pu deviner...
Posté par David Delassus (site web personnel) . Évalué à 3 (+1/-0).
Qui aurait pu deviner qu'un dépôt centralisé que tout le monde utilise, y compris des acteurs privés, qui permet à tout le monde d'y publier du code, sans aucune restriction, aucune validation, aucune revue, aucune limite, contiendrait du malware ?
On parle de NPM, mais PyPI, crates.io, CPAN, etc… ont tous le même problème.
Et même quand tu as de la revue/validation/limitation comme les dépôts officiels d'une distribution Linux, on n'est pas à l'abri.
D'un point de vue "expérience développeur", cet outillage est très pratique. Mais d'un point de vue "sécurité", je rejoins de plus en plus l'avis de Drew Devault et sa décision de ne pas supporter ça pour son langage Hare.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Qui aurait pu deviner...
Posté par aiolos . Évalué à 3 (+2/-1).
Je ne suis pas sûr que devoir aller vérifier quelle version de telle librairie disponible sur github et mise à la main dans le projet doit beaucoup plus efficace en terme de sécurité…
[^] # Re: Qui aurait pu deviner...
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0).
tu en parleras à ceux qui ont pété leur CI/CD avec is-even() :-)
disposer localement de l'intégralité de ses dépendances garantit 2-3 choses et est une bonne pratique :
normalement, il ne devrait pas y avoir besoin d'en remettre une tartine :/
[^] # Re: Qui aurait pu deviner...
Posté par aiolos . Évalué à 5 (+3/-0).
Tout ce que tu dis est faisable tout en utilisant un gestionnaire de dépendance avancé et plus ou moins centralisé, pour peu que tu utilise un repo d’artefacts dans ton infra. C’est ce qui se fait couramment depuis longtemps dans le monde java avec artifactory, et plus récemment avec ce que propose gitlab.
Mettre tes dépendances en dur dans ton repo git ne solutionne en rien les gens qui mettent n’importe quelle depedance dans leur soft, mais complique beaucoup leur suivi. En pratique, plus ton process d’update de tes dépendances est manuel, moins leur mise à jour est effectuée régulièrement. Sans parler du suivi de leur recensement.
Pour moi, le problème de base, c’est surtout le nombre énorme de dépendances triviales qui sont dans ces repos qui rendent impossible leur suivi effectif, surtout si tu rajoutes de la transitivité et les versions multiples que ca ramène. Et aussi, les pratiques qui consistent à ne pas se soucier des dépendances qu’on importe.
Et là éventuellement, il y a un avantage pour la gestion à la main : c’est tellement chiant et impactant que tu va pas être tenté de mettre un truc pour trois lignes. Maintenir le code sera largemet moins coûteux… mais c’est aussi le cas pour ceux qui ont importé is-even.
Je dirais bien que normalement on ne devrait pas avoir à en faire des tartines, mais je me retiendrai par respect pour mon interlocuteur.
[^] # Re: Qui aurait pu deviner...
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
tu ne parles pas de la même chose : j'oppose récupérer dynamiquement à gérer en local (ce que les outils que tu pointes font quasi bien), non artifactory n'est pas la solution, au mieux une solution, c'est plus une question de compréhension
ce n'est pas ce que j'indiquais (et justement une des limites que je pointe si personne ne regarde… j'ai failli dire gère mais j'y crois peu :/
oui bah ça, tu prends un développeur pour taper sur l'autre et tu vas prendre un café…
yep :/ peu le font effectivement, déjà que comprendre qu'ils peuvent le patcher voire remonter un bug upstream leur est une grande inconnue o_O
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.