Fût un temps où les contenus téléchargés étaient soigneusement vérifiés, à minima avec un hash ; où les développeurs n'ignoraient pas que même un vulgaire copié/collé d'une ligne de shell depuis un site internet était un risque majeur pour la sécurité…
Vive la course à la productivité.
En ce temps là on gardait aussi pendant des mois/années plein de vieilles librairies et programmes troués jusqu'à la moelle parce qu'on avait peur de mettre à jour, qu'on n'avait pas d'infra CI/CD ni de contrôle qualité.
Regarder le passé avec nostalgie c'est bien, mais sans naïveté c'est mieux.
Attention quand même à ne pas basculer dans la situation inverse.
La CI/CD existe et marche très bien sans ces gestionnaires de paquets drogués à la version latest.
Dans ma boîte, j'ai un Jenkins qui recompile tous nos logiciels, qu'ils soient en C++ ou en Python. Et on a même plusieurs environnements, SuSE 10, SuSE 11, CentOS 7, Ubuntu 20.04, avec des compilateurs différents (GCC de 7 à 9), des versions de boost différents (pour le C++), etc.
Mais TOUT est hors-ligne. C'est le développeur qui choisit la version, qui la regarde, et qui la soumet à la plateforme de CI/CD (souvent par le biais d'un dépôt Git). C'est pour moi hors de question qu'une plateforme de CI/CD aille chercher une version d'une bibliothèque sur Internet à poil.
Pour Yarn, il existe par exemple yarn install --offline --non-interactive --frozen-lockfile, et dans le lockfile, il y a les condensats des paquets. C'est sûr, le développeur ne peut pas tout vérifier, mais au moins, la plateforme de CI/CD ne fait rien en cachette.
Avant, yavait pas de CI/CD. Mais un logiciel comme Jenkins, forké en 2011 à partir de Hudson créé en 2005. Et avant ça, il existait d'autres solutions. npm est sorti en 2010. Il n'y a donc aucune excuse pour lui, d'un point de vue de la sécurité. Pareil pour pip, 2011, aucune excuse. RubyGems date de 2003, donc c'est plus excusable.
Posté par Psychofox (Mastodon) .
Évalué à 7.
Dernière modification le 11 février 2021 à 12:04.
Je dis juste que sans ignorer les problèmes actuels et soulignés ici qu'il ne faut pas idéaliser le passé et que ce qu'on faisait dans le passé n'était pas forcément meilleur.
Du reste c'est pas parce qu'on est hors-ligne et qu'on fait la copie manuellement vers l'infra que le dev va lire tout le code de chaque librairie et s'assurer qu'un module n'a pas ajouté une backdoor du jour au lendemain. La plupart des devs vont seulement la choisir en se basant sur le changelog ou la liste des issues du projet pour corriger tel ou tel bug ou bénéficier d'une fonctionnalité qui les intéressent, pas lire le code lui-même. Et je ne parle même pas des librairies ou modules qui sont au 3ème ou 4e niveau de dépendance. Je dirais que c'est même un processus d'audit à part qui nécessiterait une équipe dédiée.
Dans le monde npm, il y'a des modules qui ne font qu'une poignée de lignes. D'un côté ils évoluent peu vue leur taille et sont donc facile à évaluer, de l'autre ça fait une avalanche de sous-dépendances d'un module à l'autre.
Désolé, il s'agit d'expérience personnelle : quand on avait besoin d'une librairie non fournie pendant ma thèse, il fallait procéder à une demande d'installation officielle auprès des autorités informatique et de sécurité qui ne s'empressaient pas d'installer tout et n'importe quoi. Évidemment, ça ralenti le travail. Mais peut-être ce genre de procédure est-elle un mal nécessaire pour les parties d'un système informatique où un minimum de sécurité est nécessaire ?
Posté par Psychofox (Mastodon) .
Évalué à 2.
Dernière modification le 11 février 2021 à 10:28.
Idéalement je pense que c'est un travail que devraient faire des entités comme github/gitlab/pip/rubygems/cpan/npm.
Un developpeur devrait pouvoir pousser du code sur son repo, mais un peer review indépendant et réalisé par des personnes aguérries devrait être fait à chaque pull request.
Mais on ne peut pas compter sur du volontariat seulement pour ça, il faudrait donc abandonner l'idée que ces forges et outils de distribution ne proposent plus les librairies gratuitement. On peut imaginer un intermédiaire, ceux qui ne payent pas reçoivent tout le code sans review, ceux qui payent n'ont accès qu'à du code dont chaque pull request a été soumise à une review.
Un developpeur devrait pouvoir pousser du code sur son repo, mais un peer review indépendant et réalisé par des personnes aguérries devrait être fait à chaque pull request.
Super idée. Et on appellerait ça une distribution. Et elles le feraient quel que soit le langage. En plus elles proposeraient un gestionnaire de paquet unifié, fini le gloubiboulga de composer, cargo, pip, npm, etc. Ce serait formidable et merveilleux.
Sauf que le faire au niveau de la distribution, c'est presque et un peu une perte de temps quand on parle de langage interprété qui peut être exécuté par une multitude d'OS car chaque distribution/OS doit faire le même travail. Sans compter le principe des environnements virtuels indépendants qui restent très pratique. Les repos de modules par langage ne sont pas une mauvaise idée en soi, mais la partie reviewing doit s'y faire aussi.
Et accessoirement les mainteneurs ne font pas forcément une revue de code. Il y a des failles grosses comme des baleines qui ont terminé dans les distributions, et parfois à cause des mainteneurs, la débacle openssl dans debian en est un bon exemple.
Les distributions font des revues de code ? À part RedHat qui a la maîtrise d'une partie du code qu'elle distribue (maîtrise ne signifie pas auditer), ce n'est pas le cas et je n'ai jamais vu d'empaqueteur ou de guide pour le devenir dans les distributions en faire mention.
Je n'ai pas 20 ans d'xp, mais je suis sceptique quant à ce que tu sous-entend.
Ou les dépots Maven dans le monde Java, en s'appuyant sur les noms de domaines ; apparemment, MavenCentral ajouterai une vérification pour s'assurer que celui qui pousse dans un namespace possède bien le nom de domaine correspondant.
Idéalement je pense que c'est un travail que devraient faire des entités comme github/gitlab/pip/rubygems/cpan/npm.
Un developpeur devrait pouvoir pousser du code sur son repo, mais un peer review indépendant et réalisé par des personnes aguérries devrait être fait à chaque pull request.
Je bricole un peu avec R et Python, en ayant commencé avec R (quelques années avant de commencer avec Python), et j'ai été très surpris quand je me suis aperçu que je pouvais créer un compte sur PyPI et publier des paquets que tout le monde peut dès lors installer via pip. Ça m'a fait sacrément repenser à mon usage de pip. Dans l'univers R, le dépôt de paquets s'appelle CRAN et il fonctionne comme un journal académique : tu veux publier un paquet que tout le monde pourra installer en une commande ? ok, mais il devra d'abord être passé en revue et approuvé par plusieurs personnes (qui peuvent potentiellement demander des modifications avant d'accepter la publication). CRAN fait ça surtout pour s'assurer que les méthodes statistiques implémentées dans les paquets font bien ce que dit leur description (donc pour éviter de causer des résultats faux), mais l'effet secondaire évident et appréciable c'est qu'il est virtuellement impossible de faire publier un paquet malicieux sur CRAN.
Déjà dit sur le principe, mais pour ton exemple précis la pratique réelle hors personne qui sont droites dans leurs bottes et vont tout respecter (= pas souvent) est que les gens se débrouillaient pour accélérer le processus car leur projet ne pouvait pas attendre aussi longtemps, et ils installaient comme ils pouvaient (un petit modem par ci, le PC perso par la…), avec les conséquences qui allaient avec.
Alors oui il faut gérer la sécurité et les pip install blabla c'est quand même une sacré confiance à avoir, mais avant ce n'était pas si mieux que ça (et surtout si on appliquait aujourd'hui la même lenteur tu n'aurais effectivement pas de problème de sécu vu que ta boite serait morte et toi au chômage, trop de sécurité tue bien plus que moins de sécurité, il faut un juste milieu suivant la criticité de l'endroit).
pendant ma thèse
Après certes, pour des trucs où un "time to market" n'existe pas… Ca reste un cas non général que de ne pas être trop embêté par le temps et/ou concurrence.
Après certes, pour des trucs où un "time to market" n'existe pas… Ca reste un cas non général que de ne pas être trop embêté par le temps et/ou concurrence.
Une thèse ça un temps limité (3ans, officiellement, prolongeable d'un an ou deux, rarement plus)…
Et plus généralement dans la recherche, le but c'est quand même souvent de publier à une conf précise, ou au moins à la "saison des confs", donc en pratique tu as souvent des dead-lines.
J'ai bossé avec des entreprises dans lesquelles les chercheurs avaient à leur disposition des échéance de temps largement supérieures à celles de certaines équipes universitaires, sans parler des thésards.
Je ne sais pas pourquoi tu bloques sur les deadlines, ce n'est pas la seule contrainte qui existe. Je maintiens que ce sont deux mondes qui n'ont absoluments rien à voir.
C'est lent mais ce n'est pas pour ça qu'il y a plus de vérification. J'ai eu des expériences où tu as ce genre de latence et quand c'est "fait" il n'y a aucun doute que ça a été fait par dessus la jambe.
De plus il ne faut pas surestimé les capacités de ce genre d'équipe, elles ne sont en général pas en mesure d'auditer la sécurité du code et du packaging qui va avec. Les audit de sécurité ce n'est pas simple et c'est très très chère.
Pour résumer (traduction libre):
- Utiliser les scopes
- Utiliser un fichier .npmrc à la racine du projet pour paramétrer les dépôts.
- Faites attention lors de l'utilisation d'un proxy.
- Soyez attentifs aux échecs de construction de projet.
# La faille entre la chaise et le clavier
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 8.
Fût un temps où les contenus téléchargés étaient soigneusement vérifiés, à minima avec un hash ; où les développeurs n'ignoraient pas que même un vulgaire copié/collé d'une ligne de shell depuis un site internet était un risque majeur pour la sécurité…
Vive la course à la productivité.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 10.
En ce temps là on gardait aussi pendant des mois/années plein de vieilles librairies et programmes troués jusqu'à la moelle parce qu'on avait peur de mettre à jour, qu'on n'avait pas d'infra CI/CD ni de contrôle qualité.
Regarder le passé avec nostalgie c'est bien, mais sans naïveté c'est mieux.
[^] # Re: La faille entre la chaise et le clavier
Posté par Glandos . Évalué à 10.
Attention quand même à ne pas basculer dans la situation inverse.
La CI/CD existe et marche très bien sans ces gestionnaires de paquets drogués à la version latest.
Dans ma boîte, j'ai un Jenkins qui recompile tous nos logiciels, qu'ils soient en C++ ou en Python. Et on a même plusieurs environnements, SuSE 10, SuSE 11, CentOS 7, Ubuntu 20.04, avec des compilateurs différents (GCC de 7 à 9), des versions de boost différents (pour le C++), etc.
Mais TOUT est hors-ligne. C'est le développeur qui choisit la version, qui la regarde, et qui la soumet à la plateforme de CI/CD (souvent par le biais d'un dépôt Git). C'est pour moi hors de question qu'une plateforme de CI/CD aille chercher une version d'une bibliothèque sur Internet à poil.
Pour Yarn, il existe par exemple
yarn install --offline --non-interactive --frozen-lockfile, et dans le lockfile, il y a les condensats des paquets. C'est sûr, le développeur ne peut pas tout vérifier, mais au moins, la plateforme de CI/CD ne fait rien en cachette.Avant, yavait pas de CI/CD. Mais un logiciel comme Jenkins, forké en 2011 à partir de Hudson créé en 2005. Et avant ça, il existait d'autres solutions.
npmest sorti en 2010. Il n'y a donc aucune excuse pour lui, d'un point de vue de la sécurité. Pareil pourpip, 2011, aucune excuse. RubyGems date de 2003, donc c'est plus excusable.[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 11 février 2021 à 12:04.
Je dis juste que sans ignorer les problèmes actuels et soulignés ici qu'il ne faut pas idéaliser le passé et que ce qu'on faisait dans le passé n'était pas forcément meilleur.
Du reste c'est pas parce qu'on est hors-ligne et qu'on fait la copie manuellement vers l'infra que le dev va lire tout le code de chaque librairie et s'assurer qu'un module n'a pas ajouté une backdoor du jour au lendemain. La plupart des devs vont seulement la choisir en se basant sur le changelog ou la liste des issues du projet pour corriger tel ou tel bug ou bénéficier d'une fonctionnalité qui les intéressent, pas lire le code lui-même. Et je ne parle même pas des librairies ou modules qui sont au 3ème ou 4e niveau de dépendance. Je dirais que c'est même un processus d'audit à part qui nécessiterait une équipe dédiée.
Dans le monde npm, il y'a des modules qui ne font qu'une poignée de lignes. D'un côté ils évoluent peu vue leur taille et sont donc facile à évaluer, de l'autre ça fait une avalanche de sous-dépendances d'un module à l'autre.
[^] # Re: La faille entre la chaise et le clavier
Posté par xcomcmdr . Évalué à 7.
[référence nécessaire]
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: La faille entre la chaise et le clavier
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Désolé, il s'agit d'expérience personnelle : quand on avait besoin d'une librairie non fournie pendant ma thèse, il fallait procéder à une demande d'installation officielle auprès des autorités informatique et de sécurité qui ne s'empressaient pas d'installer tout et n'importe quoi. Évidemment, ça ralenti le travail. Mais peut-être ce genre de procédure est-elle un mal nécessaire pour les parties d'un système informatique où un minimum de sécurité est nécessaire ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 11 février 2021 à 10:28.
Idéalement je pense que c'est un travail que devraient faire des entités comme github/gitlab/pip/rubygems/cpan/npm.
Un developpeur devrait pouvoir pousser du code sur son repo, mais un peer review indépendant et réalisé par des personnes aguérries devrait être fait à chaque pull request.
Mais on ne peut pas compter sur du volontariat seulement pour ça, il faudrait donc abandonner l'idée que ces forges et outils de distribution ne proposent plus les librairies gratuitement. On peut imaginer un intermédiaire, ceux qui ne payent pas reçoivent tout le code sans review, ceux qui payent n'ont accès qu'à du code dont chaque pull request a été soumise à une review.
[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 2.
Il y a une double négation de trop dans ma phrase sur l'abandon de la gratuité.
[^] # Re: La faille entre la chaise et le clavier
Posté par jyes . Évalué à 10.
Super idée. Et on appellerait ça une distribution. Et elles le feraient quel que soit le langage. En plus elles proposeraient un gestionnaire de paquet unifié, fini le gloubiboulga de composer, cargo, pip, npm, etc. Ce serait formidable et merveilleux.
Ouvre les yeux, s’étire et baille…
Mais qu’a-t-on fait en 20 ans ? On a tout cassé !
[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 6.
Sauf que le faire au niveau de la distribution, c'est presque et un peu une perte de temps quand on parle de langage interprété qui peut être exécuté par une multitude d'OS car chaque distribution/OS doit faire le même travail. Sans compter le principe des environnements virtuels indépendants qui restent très pratique. Les repos de modules par langage ne sont pas une mauvaise idée en soi, mais la partie reviewing doit s'y faire aussi.
Et accessoirement les mainteneurs ne font pas forcément une revue de code. Il y a des failles grosses comme des baleines qui ont terminé dans les distributions, et parfois à cause des mainteneurs, la débacle openssl dans debian en est un bon exemple.
[^] # Re: La faille entre la chaise et le clavier
Posté par barmic 🦦 . Évalué à 3.
Les distributions font des revues de code ? À part RedHat qui a la maîtrise d'une partie du code qu'elle distribue (maîtrise ne signifie pas auditer), ce n'est pas le cas et je n'ai jamais vu d'empaqueteur ou de guide pour le devenir dans les distributions en faire mention.
Je n'ai pas 20 ans d'xp, mais je suis sceptique quant à ce que tu sous-entend.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La faille entre la chaise et le clavier
Posté par Anonyme . Évalué à 2.
Commencer par segmenter dans des espaces de noms, ça me paraît déjà un bon début pour éviter le problème mentionné dans l’article.
Si on prend l’exemple de JavaScript et npm, c’est ce que fait entropic (écrit par l’auteur de The economics of package management)
[^] # Re: La faille entre la chaise et le clavier
Posté par aiolos . Évalué à 4.
Ou les dépots Maven dans le monde Java, en s'appuyant sur les noms de domaines ; apparemment, MavenCentral ajouterai une vérification pour s'assurer que celui qui pousse dans un namespace possède bien le nom de domaine correspondant.
[^] # Re: La faille entre la chaise et le clavier
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 7.
Je bricole un peu avec R et Python, en ayant commencé avec R (quelques années avant de commencer avec Python), et j'ai été très surpris quand je me suis aperçu que je pouvais créer un compte sur PyPI et publier des paquets que tout le monde peut dès lors installer via
pip. Ça m'a fait sacrément repenser à mon usage depip. Dans l'univers R, le dépôt de paquets s'appelle CRAN et il fonctionne comme un journal académique : tu veux publier un paquet que tout le monde pourra installer en une commande ? ok, mais il devra d'abord être passé en revue et approuvé par plusieurs personnes (qui peuvent potentiellement demander des modifications avant d'accepter la publication). CRAN fait ça surtout pour s'assurer que les méthodes statistiques implémentées dans les paquets font bien ce que dit leur description (donc pour éviter de causer des résultats faux), mais l'effet secondaire évident et appréciable c'est qu'il est virtuellement impossible de faire publier un paquet malicieux sur CRAN.[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 2.
Ça ne marche pas comme ça. On ne peut pas just "siloter" et se dire que ça va aller.
[^] # Re: La faille entre la chaise et le clavier
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 11 février 2021 à 10:53.
Déjà dit sur le principe, mais pour ton exemple précis la pratique réelle hors personne qui sont droites dans leurs bottes et vont tout respecter (= pas souvent) est que les gens se débrouillaient pour accélérer le processus car leur projet ne pouvait pas attendre aussi longtemps, et ils installaient comme ils pouvaient (un petit modem par ci, le PC perso par la…), avec les conséquences qui allaient avec.
Alors oui il faut gérer la sécurité et les pip install blabla c'est quand même une sacré confiance à avoir, mais avant ce n'était pas si mieux que ça (et surtout si on appliquait aujourd'hui la même lenteur tu n'aurais effectivement pas de problème de sécu vu que ta boite serait morte et toi au chômage, trop de sécurité tue bien plus que moins de sécurité, il faut un juste milieu suivant la criticité de l'endroit).
Après certes, pour des trucs où un "time to market" n'existe pas… Ca reste un cas non général que de ne pas être trop embêté par le temps et/ou concurrence.
[^] # Re: La faille entre la chaise et le clavier
Posté par aiolos . Évalué à 2.
Une thèse ça un temps limité (3ans, officiellement, prolongeable d'un an ou deux, rarement plus)…
Et plus généralement dans la recherche, le but c'est quand même souvent de publier à une conf précise, ou au moins à la "saison des confs", donc en pratique tu as souvent des dead-lines.
[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 11 février 2021 à 12:06.
Deadline ou pas je crois qu'on ne peut pas comparer le monde universitaire avec le monde de l'entreprise.
[^] # Re: La faille entre la chaise et le clavier
Posté par aiolos . Évalué à 6.
J'ai bossé avec des entreprises dans lesquelles les chercheurs avaient à leur disposition des échéance de temps largement supérieures à celles de certaines équipes universitaires, sans parler des thésards.
[^] # Re: La faille entre la chaise et le clavier
Posté par Psychofox (Mastodon) . Évalué à 2.
Je ne sais pas pourquoi tu bloques sur les deadlines, ce n'est pas la seule contrainte qui existe. Je maintiens que ce sont deux mondes qui n'ont absoluments rien à voir.
[^] # Re: La faille entre la chaise et le clavier
Posté par barmic 🦦 . Évalué à 4.
C'est lent mais ce n'est pas pour ça qu'il y a plus de vérification. J'ai eu des expériences où tu as ce genre de latence et quand c'est "fait" il n'y a aucun doute que ça a été fait par dessus la jambe.
De plus il ne faut pas surestimé les capacités de ce genre d'équipe, elles ne sont en général pas en mesure d'auditer la sécurité du code et du packaging qui va avec. Les audit de sécurité ce n'est pas simple et c'est très très chère.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Petit guide pour NPM avec GitHub
Posté par Glandos . Évalué à 2.
https://github.blog/2021-02-12-avoiding-npm-substitution-attacks/
Pour résumer (traduction libre):
- Utiliser les scopes
- Utiliser un fichier
.npmrcà la racine du projet pour paramétrer les dépôts.- Faites attention lors de l'utilisation d'un proxy.
- Soyez attentifs aux échecs de construction de projet.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.