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.
Oui, mais ça me semble mieux que l'alternative où chaque paquet serait hébergé sur sa propre infrastructure. Avec un truc centralisé (ou quelques), il y a des admins qui peuvent supprimer les paquets problématiques une fois découvert.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
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).
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.
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.
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.
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
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.
Posté par Misc (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.
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.
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.
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.).
# Personne n'est à l'abri
Posté par David Delassus (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 Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Personne n'est à l'abri
Posté par claudex . Évalué à 5.
Oui, mais ça me semble mieux que l'alternative où chaque paquet serait hébergé sur sa propre infrastructure. Avec un truc centralisé (ou quelques), il y a des admins qui peuvent supprimer les paquets problématiques une fois découvert.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Personne n'est à l'abri
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Jusqu'au jour où les admins du dépôt disent "salut, on ferme, désolé!"
Et là toutes tes dépendances sont toutes cassées d'un seul coup en même temps.
[^] # Re: Personne n'est à l'abri
Posté par David Delassus (site web personnel) . Évalué à 4.
Sauf qu'il met en garde contre l'utilisation des packages managers, pas des dépôts.
C'est comme dire :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Personne n'est à l'abri
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 13 mai 2022 à 16:59.
Oui mais ici c'est pas l'utilisation aveugle de curl, c'est la confiance aveugle à
http://mon-super-virus.com/fuck-you.shhttps://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Personne n'est à l'abri
Posté par nico4nicolas . Évalué à 2.
J'ai testé, ça ne fonctionne pas. Apparemment le lien n'est pas le bon… CQFD
[^] # Re: Personne n'est à l'abri
Posté par Anonyme . Évalué à 2. Dernière modification le 12 mai 2022 à 17:42.
je vais foncer acheter le domaine et poser un fuck-you.sh à la racine !
EDIT: blague à part, il vaut mieux delinkifier cette adresse
[^] # Re: Personne n'est à l'abri
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Fait. Mais c'est pour ça qu'on utilise des domaines en
.invaliddans les exemples que l'on donne.[^] # Re: Personne n'est à l'abri
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 14 mai 2022 à 04:27.
ou juste les domaines
example.(com|net|org)?“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Personne n'est à l'abri
Posté par Benoît Sibaud (site web personnel) . Évalué à 5. Dernière modification le 14 mai 2022 à 10:49.
Et .example aussi.
https://en.m.wikipedia.org/wiki/.example
https://en.m.wikipedia.org/wiki/Example.com
https://en.m.wikipedia.org/wiki/.invalid
https://datatracker.ietf.org/doc/html/rfc2606
https://datatracker.ietf.org/doc/html/rfc6761
(Wikipedia mentionne aussi example.edu mais je ne le vois pas dans les RFC)
[^] # Re: Personne n'est à l'abri
Posté par napster2core . É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 David Delassus (site web personnel) . Évalué à 1. Dernière modification le 12 mai 2022 à 15:49.
Pas dans cet article en tout cas.
Et la technologie est strictement la même :
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 barmic 🦦 . É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 David Delassus (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 Barnabé . É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
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 ElVirolo (site web personnel) . Évalué à 2.
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 Misc (site web personnel) . Évalué à 3. Dernière modification le 12 mai 2022 à 23:38.
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 David Delassus (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é.
poetry publishyarn publishcargo publishPar contre :
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"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 Misc (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 ElVirolo (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.