Comment (et pourquoi) un membre de l'équipe TuxCare contribue à un logiciel open-source

Dans certains de nos articles précédents, nous avons abordé la relation étroitement intégrée entre les logiciels à code source ouvert - qui sont essentiellement gratuits - et les organisations commerciales qui s'appuient sur ces logiciels.

L'un des points que nous avons abordés est qu'il est courant que des employés payés par des organisations commerciales contribuent à des projets de logiciels libres, sans que leur employeur ne reçoive un avantage financier direct de ce travail.

Les motivations derrière cette générosité sont diverses. Parfois, une organisation à vocation commerciale a simplement besoin d'ajouter des fonctionnalités à un projet à code source ouvert par intérêt personnel. Cependant, il s'agit souvent d'une relation symbiotique entre les utilisateurs de logiciels libres et la communauté des logiciels libres.

Pour cet article, nous avons parlé à l'un des développeurs de l'équipe TuxCare - Dmitry Antipov - pour savoir comment l'équipe TuxCare contribue aux logiciels libres. Continuez à lire pour voir comment Dmitry travaille avec des logiciels open-source dans son travail quotidien chez TuxCare, et quelles sont les motivations derrière TuxCare et les contributions de Dmitry aux logiciels open-source.

Signaler un problème clé dans le RPM

Dmitry a commencé à travailler en tant qu'ingénieur logiciel en 1998, travaillant principalement sur une série de projets Linux, y compris le noyau Linux et une série d'autres tâches de développement de systèmes généraux. Une grande partie de cette expérience a été acquise dans l'environnement des entreprises. Actuellement, Dmitry travaille avec l'équipe Extended Lifecycle Support (ELS) chez TuxCare, mais il contribue également à une série de projets open-source au cours de son travail quotidien chez TuxCare.

Parfois, ce travail découle d'un besoin observé. Prenons le cas des paquets RPM. Un membre de la communauté a remarqué que, pour les paquets RPM, les sous-clés révoquées ne sont en fait pas vérifiées lorsqu'une signature valide est vérifiée pour un paquet. Ainsi, même si une sous-clé a été révoquée, elle sera toujours acceptée.

Cela a incité Dmitry à enquêter sur le problème - qui était plutôt critique étant donné que pendant de nombreuses années, les utilisateurs de distributions Linux basées sur RPM ont pu installer des paquets dont les signatures n'étaient pas correctement validées.

La chance - pour l'instant

Alors que RPM et libdnf vérifient si une clé est valide et non expirée, aucun ne vérifie la révocation. Heureusement, aucune des distributions RPM n'a été touchée par une attaque basée sur cette faille.

Selon Dmitri, c'est essentiellement une chance que les clés n'aient pas eu besoin d'être révoquées comme cela a été le cas lors du piratage de l'autorité de certification de Norton. Et, par conséquent, les clés utilisées pour signer les paquets RPM ont été stockées correctement et n'ont jamais été révoquées.

Dmitri dit qu'une partie du problème est que les projets de gestion de paquets se concentrent sur la gestion des paquets plutôt que sur la cryptographie. C'est normal, et il n'y a pas besoin pour RPM de mettre en place ses propres bibliothèques de cryptographie. Néanmoins, Dmitri a signalé le problème et, en temps voulu, l'équipe responsable de la gestion des paquets RPM y remédiera, bien que la question de savoir quand cela se produira reste ouverte.

Contribuer à GlusterFS

L'un des aspects les plus puissants de la communauté des logiciels libres est la manière dont elle continue à répondre aux besoins technologiques les plus contemporains grâce à des projets d'avant-garde menés par la communauté.

GlusterFS est l'un de ces projets. Pour répondre aux besoins des environnements de serveurs distribués en constante évolution, une équipe d'utilisateurs a commencé à construire un système de fichiers distribué qui peut être mis à l'échelle de manière arbitraire.

Le système de fichiers peut gérer plusieurs pétaoctets de stockage sur des centaines de notes et constitue une solution populaire pour le stockage dorsal dans les environnements virtuels distribués. Cependant, comme pour tous les autres projets open-source, GlusterFS a besoin de l'apport continu de la communauté. Il a plus de dix ans, après tout.

En discutant avec Dmitri, il est rapidement apparu qu'il contribue à GlusterFS d'une manière importante. Depuis un certain temps, Dmitri travaille sur les couches inférieures du système GlusterFS, là où la logique du système de haut niveau rencontre le système d'exploitation. Il a notamment travaillé sur les fichiers, les sockets, les threads, la synchronisation, etc. Plus récemment, il a résolu certains problèmes liés à l'utilisation de mutex non initialisés, qui, bien qu'un outil comme valgrind puisse les détecter assez facilement, ont quand même trouvé leur chemin dans la base de code. Il a également corrigé du code lié à la finalisation des threads, où certains threads sortants ne libéraient pas correctement l'espace de la pile, ce qui entraînait des fuites de mémoire.

Corriger le problème croissant des mutex

Nos lecteurs réguliers auront remarqué que nous avons récemment couvert des failles de sécurité dans toute une série de vulnérabilités, et que des préoccupations concernant l'utilisation des mutex et des futex ont été soulevées, plusieurs CVE signalant des failles dans leur utilisation.

En effet, certaines des contributions de Dmitry à GlusterFS portaient sur les mutex - en essayant de résoudre les problèmes de fuites de ressources. Selon Dmitry, lorsque les mutex ne sont plus nécessaires, ils doivent être libérés - sinon, une fuite de ressources, petite mais visible, se produit. Bien que ce ne soit pas aussi grave qu'une fuite de mémoire, il est toujours nécessaire d'adopter des pratiques de programmation aseptisées, et les ressources doivent toujours être nettoyées après utilisation.

Travailler sur l'open source au sein de TuxCare

RPM et GlusterFS ne sont que deux exemples des contributions de Dmitri au sein de la communauté open source. L'élément intéressant du travail de notre développeur est le fait qu'il consomme presque tout son temps chez TuxCare.

En d'autres termes, Dmitri s'attache surtout à contribuer à des projets open-source, même s'il travaille au sein de l'équipe Extended Lifecycle Support (ELS). Nous avons demandé à Dmitri comment cela s'inscrit dans le cadre des prérogatives d'une organisation commerciale.

Selon Dmitri, TuxCare a l'intention d'être considéré comme un membre précieux du mouvement open-source, et que la volonté de fournir des contributions aux projets open-source vient du niveau de la direction. En partageant avec les projets en amont le code créé pour corriger les problèmes identifiés dans les distributions Linux couvertes par ELS, ces corrections seront disponibles pour tous, contribuant ainsi à un environnement informatique plus sûr dans son ensemble.

Dmitri dit qu'il continuera probablement à contribuer aux projets open-source, ajoutant à une longue liste de contributions existantes qui, au-delà de ce que nous avons déjà mentionné, comprend également une synchronisation du backend du système de fichiers basée sur POSIX AIO et un support amélioré pour l'exécution de différents vérificateurs Valgrind.

L'histoire de Dmitri a TuxCare montre comment les fournisseurs commerciaux travaillent en étroite collaboration avec les membres de la communauté open source pour contribuer aux projets open source. Ensemble, nous faisons avancer le projet open source et veillons à ce que toutes les organisations, qu'elles soient gouvernementales, non gouvernementales ou à but lucratif, puissent continuer à s'appuyer sur une base de code open source performante et sécurisée.