Greboca  

Suport technique et veille technologique

Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.

C’est alors la barrière de la prise en main qui fait peur, et pourtant...

Les logiciels libres

L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.

Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.

Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.

Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.

Un blog furtif  -  OSQI

 -  3 avril - 

Ce texte est une traduction d'un article intitulé « OSQI » publié par Tim Bray, sur son site web « ongoing » le 1er avril 2024.

***

Je propose la création d'un ou plusieurs « Open Source Quality Institutes ». Un OSQI est une organisation du secteur public qui emploie des ingénieurs en logiciel. Sa mission serait d'améliorer la qualité, et en particulier la sécurité, des logiciels libres populaires.

Pourquoi ? - La porte dérobée XZ Utils (disons simplement #XZ) est à l'origine de ce qui m'a conduit à cette idée. Si vous vous penchez sur cette histoire, il devient évident que la vulnérabilité clé n'était pas technique, mais était liée au fait qu'un grand nombre de logiciels open source sont sous-maintenus ou négligés, parce qu'ils ne s'appuient pas sur une logique commerciale permettant de payer des gens pour s'en occuper. Ce qui est un problème, parce qu'il existe de bonnes raisons de payer des gens pour les attaquer.

D'autres activités humaines essentielles ne sont pas rentables, comme l'enseignement supérieur, la qualité de l'eau potable et la réglementation financière. Pour ces activités, nous créons des structures non capitalistes telles que des universités, des instituts et des agences, parce que la société a besoin que ces choses soient faites, même si personne ne peut gagner de l'argent en les faisant.

Je pense que nous devons accorder plus d'attention à la qualité en général, et à la sécurité en particulier, des logiciels libres qui sont devenus la plate-forme sous-jacente de plus ou moins notre civilisation. D'où l'OSQI.

Ils veulent notre peau - Pour moi, les deux grandes leçons de #XZ sont d'abord le manque de ressources pour soutenir une infrastructure open source cruciale, mais ensuite et surtout la démonstration que les attaquants sont nombreux, compétents et patients. Nous savions déjà que les attaquants étaient nombreux et compétents, mais cet épisode, où l'attaquant était déjà bien implanté dans le projet dès mai 2022, a ouvert quelques yeux, dont les miens.

L'avantage, pour les différents types de malfaiteurs, de subvertir les pièces maîtresses de l'infrastructure open source est incalculable. Nous avons repéré #XZ ; combien en avons-nous manqué ?

Qu'est-ce que l'OSQI ? - C'est une organisation créée par un gouvernement national. Il est évident que plus d'une nation peut avoir un OSQI.

La grande majorité du personnel serait composée d'ingénieurs logiciels relativement expérimentés, avec un petit pourcentage de personnes paranoïaques non spécialisées dans la sécurité informatique. Il est possible de faire beaucoup avec seulement 250 personnes, et le coût supporté serait insignifiant pour un gouvernement important.

Puisqu'il est évident que toutes les entreprises du monde ayant un chiffre d'affaires d'un milliard ou plus dépendent de l'open source, il serait raisonnable d'imposer une taxe de, disons, 0,1 % du chiffre d'affaires à toutes ces entreprises, pour aider à soutenir ce travail. L'argent n'est pas un problème.

Structure - La sélection des progiciels qui feront l'objet de l'attention de l'OSQI sera laissée à l'organisation, bien qu'il y ait des possibilités pour quiconque de demander une vérification. L'organisation de l'ingénierie pourrait être relativement horizontale, la plupart des personnes accordant une attention individuelle à des projets individuels, puis des équipes ad hoc se formant pour la construction d'outils ou la gestion de crise lorsqu'un truc comme #XZ se produit.

Pourquoi y travaillerait-on ? - Le salaire serait correct ; moins que chez Google ou Facebook, mais un salaire décent de fonctionnaire. Il n'y aurait aucun soupçon que votre employeur essaie de rendre pire quoi que ce soit ; en fait, vous commenceriez à travailler le matin avec la certitude que vous essayez d'améliorer le monde. Le télétravail serait le mode de travail par défaut, de sorte que vous pourriez vivre dans un endroit où un salaire qui ne serait pas tout à fait celui de Google vous permettrait d'avoir un mode de vie très confortable. Il y aurait des vacances décentes, des avantages sociaux et (*ahem*) une pension de retraite.

Et il y a une certaine catégorie de personnes qui trouverait une joie quotidienne dans le fait de jeter un coup d'œil, de fouiller et de perfectionner des paquets open source dont dépendent des millions de programmeurs et (indirectement) des milliards d'êtres humains. Il y a quelques décennies, j'en aurais fait partie.

Je ne pense pas que le recrutement soit un problème.

Quels sont donc les objectifs et les non-objectifs de l'OSQI ?

Objectif : sécurité - Cela doit passer en premier. Si tout ce que l'OSQI accomplit est de déjouer quelques attaques du type de #XZ, et de rendre la vie plus difficile à ceux qui les commettent, c'est très bien.

Objectif : construction d'outils - Je pense qu'il est désormais acquis que les plus grandes surfaces d'attaque de l'open source sont les réseaux de dépendance et les outils de build. Ce sont des problèmes importants et complexes, mais faisons preuve d'audace et plaçons la barre haut :

Les logiciels libres doivent être construits de manière déterministe, vérifiable et reproductible, à partir de snapshots de code source signés. Ces snapshots doivent être exempts d'artefacts générés ; chaque élément du snapshot doit être écrit et lisible par l'homme.

Par exemple : comme l'a dit Kornel, sérieusement, rétrospectivement, #autotools lui-même est un risque massif pour la sécurité de la chaîne d'approvisionnement. Je ne plaisante pas ! Sauf que le réflexe de tout le monde c'est « Comment vous allez faire, ce truc est interdépendant avec à peu près tout ».

Il existe des alternatives ; je connais CMake et Meson. Sont-elles suffisantes ? Je n'en sais rien. Il est évident que GNU AutoHell ne peut pas être balayé de tous les recoins organiques dans lequel il se cache et qu'il infecte, mais chaque projet dont il sera éliminé présentera moins de danger pour le monde. Je pense que l'OSQI aurait la possibilité de faire de réels progrès sur ce front.

Non-objectif : fonctionnalités - L'OSQI ne devrait jamais investir de ressources techniques dans l'ajout de fonctionnalités intéressantes aux paquets open source (à l'exception peut-être des outils de build et de test). La communauté open source déborde d'énergie pour ajouter de nouvelles fonctionnalités, la plupart provenant de personnes qui veulent prendre le taureau par les cornes ou qui font face à un réel blocage au travail. Ils sont bien mieux placés pour apporter ces améliorations que n'importe qui à l'OSQI.

Objectif : maintenance - Beaucoup trop de paquets deep-infra sont de moins en moins maintenus au fur et à mesure que les gens vieillissent, sont débordés, fatigués, malades ou morts. Alors que j'écrivais ceci, un appel à l'aide m'est parvenu de Sebastian Pipping, l'excellent mainteneur d'Expat, le parser XML le plus populaire au monde, mais qui n'est pas supporté et n'est pas financé.

Et oui, il s'inscrit une tendance, qui comprend notamment le désormais célèbre paquet XZ Utils.

Je pense donc qu'une tâche utile pour l'OSQI serait de prendre en charge (idéalement partiellement) les tâches de maintenance pour de nombreux projets open source qui ont un ratio élevé d'adoption par rapport au support. Dans certains cas, l'OSQI devrait prendre une forme moins intensive, que nous appellerons « life support » [maintien en vie], où l'OSQI s'occupe des rapports de vulnérabilité mais refuse catégoriquement d'aborder les demandes de fonctionnalités, aussi triviales soient-elles, et rejette tous les PR à moins qu'ils ne viennent de quelqu'un qui est prêt à prendre en charge une partie de la charge de la maintenance.

L'un des avantages d'avoir des professionnels rémunérés qui s'en chargent est qu'ils peuvent éviter le type de harcèlement par ingénierie sociale que l'attaquant de #XZ a infligé au mainteneur de XZ-Utils (voir l'excellente chronologie de Russ Cox) et qui est malheureusement trop courant dans le monde de l'open source en général.

Objectif : analyse comparative - L'efficacité est un aspect de la qualité, et je pense qu'il serait parfaitement raisonnable que l'OSQI s'engage dans l'analyse comparative et l'optimisation. Il y a une raison non évidente à cela : #XZ a été démasqué lorsqu'un spécialiste de Postgres a remarqué des problèmes de performance.

Je pense qu'en général, si vous êtes une personne mal intentionnée et que vous essayez d'introduire une porte dérobée dans un paquetage open source, il sera difficile de le faire sans introduire des problèmes de performance. Je préconise depuis longtemps que les tests unitaires et/ou d'intégration devraient inclure un ou deux points de référence, juste pour éviter les régressions de performance bien intentionnées ; s'ils handicapent aussi les méchants, c'est un bonus.

Objectif : éducation et évangélisation - Le personnel de l'OSQI développera un pool commun de compétences approfondies pour rendre les logiciels libres plus sûrs et plus performants, et plus particulièrement pour détecter et repousser de multiples types d'attaques. Ils doivent les partager ! Blogs, conférences, etc. Il m'est même venu à l'esprit qu'il pourrait être judicieux de structurer l'OSQI en tant qu'institution éducative, autonome ou en tant qu'école supérieure de quelque chose d'existant.

Mais ce dont je parle, ce n'est pas d'articles dans le JACM avec comité de lecture, mais ce que mon père, professeur d'agriculture, appelait « vulgarisation » : transmettre les résultats de la recherche directement à ceux qui pratiquent.

Non-objectif : élaborer des normes - Le monde compte suffisamment d'organismes de normalisation. Je pourrais cependant imaginer que des employés de l'OSQI participent à l'IETF, à l'IEEE, au W3C ou à d'autres organismes, en travaillant sur des normes relatives à l'infosec.

Ce qui m'amène à...

Non-objectif : litiges - ou toute autre activité liée à l'application de la législation. L'objectif de l'OSQI est de résoudre les problèmes, de créer des outils et de partager les enseignements tirés de l'expérience. Cela sera plus facile si personne (à l'exception des attaquants) ne les considère comme une menace et si le personnel n'a pas à penser à la façon dont son travail et ses conclusions seront présentés devant un tribunal.

Et un non-objectif connexe...

Non-objectif : licences - L'intersection entre la catégorie de personnes qui feraient de bons ingénieurs OSQI et celles qui se soucient des licences open source est, heureusement, très réduite. Je pense que l'OSQI devrait accepter le paysage des licences qui existe et travailler dur pour éviter de penser à sa théologie.

Non-objectif : certification - Une fois que l'OSQI existera, l'appellation « certifié par l'OSQI » pourrait voir le jour. Mais ce serait une erreur ; l'OSQI devrait être une organisation d'ingénieurs ; le coût (mesuré par la bureaucratie requise) de la certification serait astronomique.

Objectif : transparence - L'OSQI ne peut pas se permettre d'avoir des secrets, à la seule exception des vulnérabilités fraîchement découvertes mais encore non divulguées. Et lorsque ces vulnérabilités sont divulguées, l'histoire de leur découverte et de leur caractérisation doit être partagée, entièrement et complètement. Cela semble être une base minimale pour construire le niveau de confiance qui sera nécessaire.

Paranoïa nécessaire - J'ai expliqué plus haut pourquoi l'OSQI pouvait être un lieu de travail agréable. Il y aura cependant un inconvénient : vous perdrez une partie de votre vie privée. Si l'OSQI réussit, il deviendra une cible de grande valeur pour nos adversaires. Dans le cours naturel des choses, de nombreux employés deviendront des committers sur des paquets populaires, ce qui augmentera leur attrait en tant que cibles pour les pots-de-vin ou le chantage.

Je me souviens d'un jour où un responsable de la sécurité d'un géant de l'Internet m'a dit : « Nous avons des milliers d'ingénieurs, et mon travail m'oblige à croire qu'au moins l'un d'entre eux a aussi un autre employeur ».

Je pense donc que l'OSQI doit employer un petit nombre d'experts paranoïaques en sécurité traditionnelle (pas en Infosec) pour surveiller leurs collègues, contrôler leurs finances et se méfier d'une manière générale. Ces personnes s'occuperaient également de la sécurité physique et de la sécurité du réseau de l'OSQI. Parce que les attaquants attaqueront.

Prononciation - Rime avec « bosky » [NDT : verdoyant], bien sûr. De plus, les personnes qui y travaillent sont des OSQIens. J'ai déposé le nom de domaine « osqi.org » et j'en ferai joyeusement don dans le cas, assez improbable, où cette idée aboutirait.

Vous êtes sérieux ? - Oui. Sauf que je ne parle plus avec la voix d'un employeur puissant. [NDT : Tim a travaillé pour de grands acteurs économiques de la tech]

Écoutez : pour le meilleur ou pour le pire, l'open source a gagné. [Note de l'auteur : pour le meilleur, bien sûr]. Cela signifie qu'il est devenu une infrastructure cruciale de la civilisation, que les gouvernements devraient activement soutenir et entretenir, tout comme les routes, les barrages et les réseaux électriques.

Ce n'est pas tant que l'OSQI, ou quelque chose de semblable, soit une bonne idée ; c'est que ne pas essayer d'atteindre ces objectifs, en 2024, est dangereux et insensé.

***

Retrouvez-moi sur Mastodon → mastodon-ico33ff-85636.png?1690477203

par Nicolas Vivant

Un blog furtif

Directeur de la stratégie numérique de la ville d’Échirolles (où je suis chargé de déployer les logiciels libres, de développer l’inclusion numérique et de rappeler à quel point Échirolles est une ville dynamique pour tout ce qui concerne le numérique), je suis également :Le complice de Reflets, journal en ligne indépendant que vous pouvez suivre sur Mastodon.Le comparse de Richard Monvoisin avec lequel (...)

Résistance au changement et logiciels libres

 -  28 mai - 

Selon Wikipédia, « La résistance (ou aversion) au changement ou immobilisme, consiste à désirer, et tenter d'obtenir par diverses formes de (...)


De la cybersécurité...

 -  Décembre 2023 - 

...de ce qu'elle fut, et de ce qu'elle devient.J'ai un grand respect pour ceux qui vivent la cybersécurité dans leurs tripes.Depuis les années (...)


Visioconférence et streaming libres

 -  Novembre 2023 - 

Lors de la réunion du collectif « Alpes Numérique Libre » du 26 mai 2023, Échirolles a expérimenté pour la première fois la prise de parole d'une (...)


Et donc hop, je m'enfuis !

 -  Août 2023 - 

Je viens de traduire un article de Ploum qui rejoint ce que je vis, de regarder une vidéo puis de lire un article d'Henri Lœvenbruck, et je me suis (...)


Diviser le Web

 -  Août 2023 - 

Ce texte est une traduction d'un article de Tim Berners Lee, inventeur du Web, intitulé « Marking the Web's 35th Birthday : An Open Letter » publié (...)