• # Pinning

    Posté par  . Évalué à -5.

    Autant je suis d’accord sur le vendoring, autant je trouve que le pinning c’est plutôt une bonne chose.

    En tant que dev, j’ai des ressources limitées et je peux pas garantir que mon code est compatible avec toutes les versions d’une bibliothèque externe.

    C’est pas une histoire de langage d’ailleurs, dans les langages obsolètes comme le C, c’est la même chose, c’est juste pas écrit.

    • [^] # Re: Pinning

      Posté par  (site web personnel) . Évalué à 7. Dernière modification le 23 février 2021 à 23:37.

      je peux pas garantir que mon code est compatible avec toutes les versions d’une bibliothèque externe

      C'est justement pour cela qu'on fait des versions majeures ou mineures. Si chaque logiciel impose des versions précises, il faut installer différentes versions d'une même lib et le principe des distributions n'a plus d'intérêt.
      Après c'est un choix, fedora silverblue fait un peu ça : une install de base + les flatpaks qui gèrent leurs dépendances.

      les langages obsolètes comme le C

      En quoi le C est-il obsolète ?

    • [^] # Re: Pinning

      Posté par  . Évalué à 6.

      En tant que dev, j’ai des ressources limitées et je peux pas garantir que mon code est compatible avec toutes les versions d’une bibliothèque externe.

      Donc… si dans tes dépendances, ou les dépendances de tes dépendances, il y a une dépendance stricte à la version 1.2.3 d'une libfoo qui a un trou de sécurité, alors qu'une libfoo 1.2.4 est dispo… tout le monde doit attendre que l'info de la faille remonte toute la chaîne de dépendance jusqu'à ce que tu mettes en ligne une nouvelle version ?
      Mettons que cela ne prenne que 2 jours par dépendance. Si ton appli marcel dépend de libbar qui dépend de libfoo, on est déjà à 4 jours d'une faille béante, possiblement exploitée…
      Je conçois que l'on mette une dépendance sur une version minimale d'une dépendance, mais une version stricte, j'ai beaucoup plus de mal. Par ailleurs, comment garantis-tu que ton code soit pleinement compatible avec la version X, puis quand une X+1 est disponible, compatible avec cette X+1 ? Un ensemble de tests unitaires ?

      Et du coup, question bonus : si libfoo 1.2.4 casse un programme conçu avec libfoo 1.2.3, n'est-ce-pas la faute de libfoo d'avoir rompu une règle élémentaire de compatibilité entre les versions mineures ?

    • [^] # Re: Pinning

      Posté par  . Évalué à 4.

      Non, le pinning, c'est pas une bonne chose.

      Les contraintes, oui. Par exemple, définir que marcel a besoin de libfoo >=2, <3, !2.2.1 ça peut se concevoir. Évidemment, ça ne marche que si libfoo utilise le système de version sémantique. Sinon, c'est la foire d'empoigne…

      • [^] # Re: Pinning

        Posté par  . Évalué à 2.

        Non, le pinning, c'est pas une bonne chose.

        Les contraintes, oui.

        Ok, c’est un problème de compréhension alors, pour moi le pinning c’était le fait de bloquer une dépendance à certaines versions, que ça soit une version unique ou une contrainte semver.

        Si on considère que ce sont deux choses différentes, alors je suis d’accord.

    • [^] # Re: Pinning

      Posté par  (site web personnel) . Évalué à 5.

      Ses arguments sont justes, mais les empaqueteurs n'ont pas pris la peine de considérer les "nouveaux" langages, outils et usages.

      Du point de vue du développeur:

      • comment je fais pour distribuer mon soft moi même? Chaque OS/distrib a un système différent pour lequel je devrais passer 42h d'apprentissage ;
      • comment je fais appel à un empaqueteur? Il n'y a pas de doc et aucun outil de construction et gestion de dépendance de mon langage préféré n'est pris en compte ;
      • mon soft à besoin de libs qui ne seront jamais empaquetés faute de temps, je fais comment sans faire du vendoring ?

      Solution pas glop mais qui marche: j'embarque tout dans un gros binaire (exécutable statique, flatpack, AppImage, image Docker, gros jar de la mort…) et hop tant pis pour la sécurité, l'espace disque et la consommation mémoire.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Pinning

        Posté par  . Évalué à 3.

        En tant que dev ça peut être contre productif d’essayer de packager pour une distribution en particulier et c’est même plutôt découragé (en tout cas pour Debian ou le dossier debian/ ne sera pas conservé à l’import des sources par exemple).

        Si tu tiens vraiment à ce que ça soit packagé pour une distribution à mon avis le mieux c’est de contacter les mainteneurs (en ouvrant une RFP pour Debian par exemple), sinon, je partirait vers les alternatives (FlatPak, Docker, pip, ce qui est le plus adapté).

        Comme tu le dis, c’est impossible de suivre tous les systèmes de packaging et toutes les politiques pour chacune des distributions (même en se limitant aux distribution les plus répandus).

      • [^] # Re: Pinning

        Posté par  (Mastodon) . Évalué à 6.

        Faire du dynamic linking ne t'empêche pas de bundler sur ton site perso ou ta forge ton binaire avec les librairies et ça n'empêche pas l'empaqueteur tiers de packager dynamiquement.

        Par contre si tu utilises un langage qui impose du static linking où que tes instructions de build/makefiles ne font que du statique, tu emmerdes le monde pour rien.

        C'est ce que je comprends de l'article en lien.

    • [^] # Re: Pinning

      Posté par  (site web personnel) . Évalué à 8.

      dans les langages obsolètes comme le C

      J'ai très hâte de savoir en quoi le C est obsolète.

      git is great because linus did it, mercurial is better because he didn't

  • # Quel est le problème ?

    Posté par  . Évalué à -6.

    L'argument principal (unique) c'est que en cas de faille, chaque logiciel doit pousser une nouvelle version avec la lib patché. Mais c'est encore une fois un problème qu'avec C/C++ non ?

    • [^] # Re: Quel est le problème ?

      Posté par  (site web personnel) . Évalué à 3.

      C'est un problème avec n'importe quel langage même non-compilé.

      Exemple, si ton application fournit un module python lui même au lieu de réutiliser celui du système le problème est le même.

      git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: Quel est le problème ?

        Posté par  . Évalué à -5.

        S'il n'y a pas de problème de sécurité je ne vois pas le soucis.

        • [^] # Re: Quel est le problème ?

          Posté par  . Évalué à 2.

          Mais le soucis, c'est quand il y a un problème de sécurité :)

          • [^] # Re: Quel est le problème ?

            Posté par  . Évalué à -7.

            Pour moi les problémes de sécurité sont uniquement avec des bibliothèques écritent en langage non safe (C/C++). Ce n'est pas le cas ?
            Donc si j'ai plusieurs fois une même bibliothèque python installée sur mon système en différentes versions, on peut être attristé de l'espace disque perdu. Mais a part ça….

            • [^] # Re: Quel est le problème ?

              Posté par  . Évalué à 5.

              Les langages memory safe ne protègent pas de bugs dans l’algorithme.

              • [^] # Re: Quel est le problème ?

                Posté par  . Évalué à -3.

                Et donc quel est le problème ? Beaucoup de distribution ne propose pas les dernières versions qui pourtant corrigent des bugs. Tant que la sécurité n'est pas compromise

                • [^] # Re: Quel est le problème ?

                  Posté par  . Évalué à 5.

                  La plupart des distributions qui font ça patchent les packages avec des correctifs de sécurité.

            • [^] # Re: Quel est le problème ?

              Posté par  . Évalué à 3.

              Pour moi les problémes de sécurité sont uniquement avec des bibliothèques écritent en langage non safe (C/C++). Ce n'est pas le cas ?

              Bien sûr, ce n'est pas le cas. Il y a plein de bibliothèques écrites en Python qui ont des problèmes de sécurité. Par exemple, un backend d'un site web écrit en Django, qui n'échappe pas correctement des entrées utilisateurs, menant à une injection SQL.

              Il faut mettre à jour la bibliothèque. Et pas attendre que les gens qui en dépendent se réveillent.

              • [^] # Re: Quel est le problème ?

                Posté par  . Évalué à 0.

                Bien sûr, ce n'est pas le cas. Il y a plein de bibliothèques écrites en Python qui ont des problèmes de sécurité. Par exemple, un backend d'un site web écrit en Django, qui n'échappe pas correctement des entrées utilisateurs, menant à une injection SQL.

                T'es sur un cas (très) restreint. Avec Django on exécute assez peu souvent du SQL directement, on passe par l'ORM.
                J'admets que c'est possible mais c'est facile de s'en prémunir. L'utilisateur averti peut également faire le nécessaire.

  • # Why not rely on app developer to handle security?

    Posté par  . Évalué à 2. Dernière modification le 02 mars 2021 à 15:48.

    L'auteur a écrit carrément un nouveau billet pour répondre à des arguments qui font écho à ce qui a été discuté ici : Why not rely on app developer to handle security?.

    Il y a des arguments qui ont déjà été donnés ici mais, si je me risque au TL;DR (de l'article, pas de mon avis hein :) ):

    • En tant qu'utilisateur, il y a moins de tiers à qui faire confiance quand c'est la distro qui gère
    • En tant qu'utilisateur, tu auras les correctifs plus vite car il n'y aura pas à attendre tous les projets amonts
    • Meilleur bus factor. Les distributions couramment utilisées ont plus de volontaires que la grande majorité des projets logiciels qui sont plutôt petits, voir même maintenus par une seule personne (qui est une situation courante)
    • Embarquer les bibliothèques pour connaître l'état et "garantir" le bon fonctionnement du logiciel posera toujours la question du nombre de cas testés (que se passe-t-il si les locale sont configurées différemment de la CI, que se passe-t-il si la plateforme n'est pas du x86, etc) et, paradoxalement, cela génère plus de travail puisque chaque projet aura du boulot.
    • la distribution se retrouve toujours à devoir patcher un moment ou un autre (si le mainteneur est en vacances, ne répond pas vite, ne veut pas faire une version, etc). Donc, on est quand même obligé de faire confiance à la distribution (cf point 1)

Suivre le flux des commentaires

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