• # Personne n'est à l'abri

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

    Ah ça sent la pique gratuite à ceux qui râlent que son langage Hare n'a pas de gestionnaire de paquet.

    Mais mossieur drew, le problème n'est pas le gestionnaire de paquet, le problème c'est le dépôt communautaire.

    Et Linux n'est pas à l'abri : https://www.securityweek.com/arch-linux-aur-repository-compromised (2018)

    Tu prend un npm, un pip, un cargo, un whatever, et tu leur mets un dépôt à l'accès limité, contrôlé, etc… comme les dépôts officiels des distributions, tout de suite les supply-chain attack sont amoindries (pour ne pas dire anéanties, ça reste des humains après tout).

    Dans un monde idéal, l'organisation a un dépôt privé dans lequel elle intègre ses dépendances de manière auditée et contrôlée.

    A Décathlon par exemple, il y avait un repository Maven interne et une impossibilité d'utilise le repo public. Tu as besoin d'une lib qui est pas dispo ? Tu fais une demande à l'équipe en charge pour auditer la dep et l'intégrer.

    Tiens, bizarrement, ils ont pas de supply chain attack. Comme c'est étrange.

    DISCLAIMER: Toutes les organisations n'ont pas les moyens de mettre ça en place. Mais qu'on arrête de blamer les gestionnaires de paquets pour les problèmes de sécurités des DÉPÔTS PUBLIC.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 8.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Personne n'est à l'abri

      Posté par  . Évalué à 6.

      Je me trompe peut-être mais j'ai plus l'impression qu'il fait une comparaison entre les gestionnaires de paquets "langage" (pypi, npm, etc) et il compare leur organisation/fonctionnement à l'organisation/fonctionnement des dépôts de nos distribution, qui utilisent un fonctionnement différent.

      Je dois avouer que s'inspirer de l'organisation des mainteneurs Debian par exemple ne ferait pas de mal à certain système de distribution de paquets.

      Après c'est aussi un milieu complexe, les besoins d'un système stable ne sont pas toujours compatible avec l'utilisation de la dernière version de la libX. Mais la réflexion autours des deux méthodes ne peut qu'être enrichissante (à moins de faire le troll).

      Si tu ne sais pas demande, si tu sais partage !

      • [^] # Re: Personne n'est à l'abri

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 12 mai 2022 à 15:49.

        j'ai plus l'impression qu'il fait une comparaison entre les gestionnaires de paquets "langage" (pypi, npm, etc) et il compare leur organisation/fonctionnement à l'organisation/fonctionnement des dépôts de nos distribution

        Pas dans cet article en tout cas.

        Et la technologie est strictement la même :

        • archiver du code ou des binaires
        • télécharger cette archive
        • résolution des dépendances
        • base de données (via fs avec des metadata ou sqlite comme pkgin, ou autre) pour stocker ces infos
        • extraire l'archive quelque part

        Donc vraiment, c'est un abus de langage de parler du gestionnaire de paquet quand en vérité on parle du dépôt.

        https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

        • [^] # Re: Personne n'est à l'abri

          Posté par  . Évalué à 2.

          Il y a tout de même pas mal de façons de faire ces choses là. Résoudre les dépendances c'est un problème np-chiant dans le cas général. C'est une résolution 3-SAT. La possibilité de signer les dépendances peut être intéressante même si tu gère ton dépôt interne. La stabilité du résultat est pas toujours garantie non plus ce qui pose problème des problèmes de reproductibilité. Et j'en oublie probablement.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Personne n'est à l'abri

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

            C'est pas le sujet.

            Le sujet c'est la confusion entre gestionnaire de paquet et dépôt de paquet.

            Oui il existe plusieurs manière de résoudre les dépendances, il n'empêche que tout les gestionnaires de paquets le font. Le reste c'est du détail technique.

            https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

            • [^] # Re: Personne n'est à l'abri

              Posté par  . Évalué à 1.

              J'ai l'impression que la confusion est moins présente que tu ne la voies, et que n'es pas très objectif sur l'article qui parle plus d'organisation et de politique que du coté technique des logiciels gérant des paquets.

              En particulier

              1 - Establish package maintainers independent of the vendors
              2 - Establish a review process for package updates

              Après il dit qu'il y a certaines fonctionnalités de ces logiciels qui aident à limiter les risques, comme les signatures et la disponibilité de mirroirs

        • [^] # Re: Personne n'est à l'abri

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

          Pas dans cet article en tout cas.

          Si, c'est exactement ce qu'il fait dans cet article. S'il préfère les gestionnaires de paquets des distributions, ce n'est pas tant pour leur qualités intrinsèques (qui, comme tu le dis, ne pas tellement différentes de celles des autres systèmes) que pour, essentiellement, le système de contrôle (et de « contrôlabilité ») de la qualité des paquets, comme il le dit à la fin de l'article.

      • [^] # Re: Personne n'est à l'abri

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 12 mai 2022 à 23:38.

        Je dois avouer que s'inspirer de l'organisation des mainteneurs
        Debian par exemple ne ferait pas de mal à certain système de
        distribution de paquets.

        Le souci, c'est que la communauté ne veut pas faire de gestions de paquets. Si on regarde les graphs respectifs des packageurs Debian et du nombre de modules écrit dans un language, on voit que les distributions ont atteint un palier, et pas l'écriture de code. Il n'y a rien qui empêche de faire des paquets et de les envoyer dans Debian. Il n'y a rien qui interdit de n'utiliser que les outils sous forme de paquets dans Debian.

        Mais c'est pas ce qui est fait. Collectivement, il semble que la majorité a décidé de faire les choses autrement.

        • [^] # Re: Personne n'est à l'abri

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

          Concrètement, ce que j'observe c'est que l'UX (ou DX pour Developer Experience ?) a pris le pas sur la sécurité.

          • Mettre à disposition un paquet Python : poetry publish
          • Mettre à disposition un paquet Node : yarn publish
          • Mettre à disposition une crate Rust : cargo publish

          Par contre :

          • Mettre à disposition un paquet Debian : trop long, ça vaudrait le coup d'en faire un journal, ou alors un lien pour télécharger le .deb (cc Windows)
          • Ubuntu : on passe via les PPA (même soucis que python/node/rust/…)
          • Archlinux : on passe via les AUR (même soucis que python/node/rust/…)

          Il serait possible je pense de "crowdsourcer" la review, comme l'ancien greenlight de Steam :

          • poetry/yarn/cargo publish : ton paquet est en mode "review"
          • après un certain nombre de review par les utilisateurs volontaires (n'importe qui dans le monde), le paquet est publié
          • on pourrait déterminer le nombre de review en fonction du nombre de paquet qui en dépendent ?

          Comme ça, pour le développeur, c'est toujours aussi simple de distribuer ce qu'il fait. Et pour l'utilisateur, on a une certaine confiance basée sur le fait qu'il y a plus de personnes bienveillantes que de personnes malveillantes.

          Ça éviterait au passage d'avoir des mise à jour de lib toutes les trois minutes (oui c'est toi que je vise eslint !!!).

          Le système de review pourrait même se baser sur dependabot pour notifier les gens qui en dépendent qu'il y a une nouvelle version à review.

          https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

          • [^] # Re: Personne n'est à l'abri

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

            Alors, vérifier si les mises à jours sont corrects, Fedora propose ça, et pareil, les gens ne se bousculent pas au portillon.

            Même si je pense qu'on pourrait rendre ça plus simple (j'avais plusieurs idées), ça ne change rien au fait qu'à un moment, tu va avoir le souci de soit n'avoir aucun humain dans la boucle car on s'oriente vers l'automatisation (et donc, une backdoor peut se retrouver la), soit d'avoir des humains mais pas assez, car ce que l'industrie en général récompense, et la communauté du logiciel libre en particulier, c'est de faire plus de code.

            Pas de faire de la maintenance que personne ne voit. Pas de faire de la relecture. Pas de faire de la doc.

            Comme je dit si souvent, on connaît les noms des fondateurs de projets les plus importants. On connaît pas le nom des testeurs, des traducteurs ou des personnes qui font de la doc ou de l'admin sys pour la majorité des projets (cad les projets sauf ceux ou on est impliqué).

            Aussi longtemps qu'il y a ce genre de dynamique sociale, ça va continuer. La sécurité et la maintenance, c'est pas glamour. Ça le sera sans doute pas de si tôt.

    • [^] # Re: Personne n'est à l'abri

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

      Soit on n'a pas lu le même article, soit je ne sais pas lire (ce qui est fort possible), soit c'est exactement ce qu'il dit.

      Il ne parle pas tant de la nature de l'un ou l'autre des gestionnaire de paquets en tant que telle (système ou « overlay ») que des caractéristiques qui leur sont traditionnellement associées. D'où sa conclusion : « For my part, I’ll stick to the system package manager. But if you think that the overlay package manager can do it better: prove it. » (sous-entendu : mettez en place un système de contrôle/review/mainteneur du paquet indépendant du mainteneur du projet, voire des builds reproductibles, etc.).

Suivre le flux des commentaires

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