• # Episode 354

    Posté par  (site web personnel) . Évalué à 4. 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  (site web personnel) . Évalué à 3.

    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  . Évalué à 3.

      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  (site web personnel) . Évalué à 4.

        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 :/

        • [^] # Re: Qui aurait pu deviner...

          Posté par  . Évalué à 5.

          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  (site web personnel) . Évalué à 3.

            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

Suivre le flux des commentaires

Note : les commentaires appartiennent Ă  celles et ceux qui les ont postĂ©s. Nous n’en sommes pas responsables.