Fedora et openSUSE retirent l’environnement de bureau Deepin : ce qui s’est passé

Deux grandes distributions Linux communautaires — Fedora et openSUSE — ont récemment pris la décision de retirer l’environnement de bureau Deepin (DDE) de leurs dépôts officiels. Même si ces décisions ne sont pas intervenues exactement au même moment, elles reposent sur des préoccupations similaires : sécurité du code, respect des règles de packaging et difficulté à maintenir le logiciel selon les standards attendus par ces projets.

Ces choix illustrent un principe central dans l’écosystème Linux : même un environnement de bureau apprécié pour son design et ses fonctionnalités peut être écarté si son intégration ne répond pas aux exigences de sécurité et de maintenance des distributions.

La décision de Fedora

Dans le cas de Fedora, la décision a été prise par le Fedora Engineering Steering Committee (FESCo), l’organe chargé des orientations techniques et des politiques de packaging du projet.

Le comité a décidé de retirer et de mettre à la retraite les paquets Deepin présents dans la distribution.

Deux raisons principales ont motivé ce choix :

• Des inquiétudes persistantes concernant la sécurité de certains composants de l’écosystème Deepin
• Une activité de maintenance jugée insuffisante, rendant difficile la correction rapide de vulnérabilités ou l’assurance d’un suivi durable

Les développeurs Fedora ont également signalé qu’il était parfois difficile de contacter certains mainteneurs des paquets Deepin. Dans une distribution communautaire, cette réactivité est essentielle : sans réponses rapides des mainteneurs, il devient compliqué de corriger des failles de sécurité ou de maintenir les paquets à jour.

Face à ces incertitudes, Fedora a conclu que maintenir Deepin dans ses dépôts officiels ne répondait plus aux standards de sécurité du projet.

Le précédent d’openSUSE

La décision de Fedora n’est pas apparue dans le vide. openSUSE avait déjà retiré Deepin de ses dépôts quelque temps auparavant, invoquant des violations de ses politiques de sécurité et de packaging.

Le problème majeur identifié par l’équipe sécurité d’openSUSE concernait un contournement des mécanismes standards de packaging RPM. Un mainteneur communautaire avait mis en place une solution permettant d’installer certains composants restreints sans passer par le processus habituel de vérification de sécurité.

Pour openSUSE, cela représentait une violation sérieuse des règles du projet, car les composants pouvant interagir avec des parties sensibles du système doivent normalement passer par des audits stricts avant d’être distribués.

Après la découverte de ce contournement, les paquets Deepin ont été retirés des distributions openSUSE jusqu’à résolution complète des problèmes.

Lorsque Fedora a examiné ses propres paquets Deepin, les préoccupations soulevées par openSUSE faisaient déjà partie du contexte.

Les inquiétudes techniques : D‑Bus et Polkit

Au-delà des questions de packaging, plusieurs problèmes de sécurité techniques ont été soulevés lors de différentes revues du code Deepin.

Certaines analyses ont notamment pointé :

• des services D‑Bus potentiellement exposés
• des risques liés à la gestion des privilèges via Polkit (PolicyKit)

D‑Bus est un système de communication interne entre applications et services Linux. S’il est mal configuré ou insuffisamment protégé, il peut permettre à des applications d’accéder à des fonctions sensibles du système.

Les critiques ont aussi concerné le service D‑Bus du gestionnaire de fichiers de Deepin, dont l’audit de sécurité était en cours depuis plusieurs années sans parvenir à une conclusion stable. Selon les examinateurs, certaines corrections ne réglaient que partiellement les problèmes ou introduisaient de nouveaux risques lors de mises à jour ultérieures.

Dans ce contexte, maintenir ces composants dans une distribution exigeant des garanties fortes en matière de sécurité devenait difficile.

Le rôle de la collaboration avec les développeurs amont

Un autre facteur important a été la communication avec le projet Deepin en amont (upstream).

Les mainteneurs de distributions comme openSUSE ont indiqué avoir rencontré des difficultés pour faire traiter certains problèmes signalés. Dans plusieurs cas, les correctifs proposés n’auraient pas entièrement résolu les problèmes identifiés ou auraient été incomplets.

Pour les distributions Linux, la collaboration avec les développeurs originaux du logiciel est essentielle. Sans coopération efficace, il devient plus compliqué de :

• auditer correctement le code
• confirmer qu’une vulnérabilité est réellement corrigée
• maintenir des correctifs sur la durée

Cette situation, combinée aux violations de règles de packaging et aux inquiétudes techniques, a contribué à la décision de supprimer Deepin des dépôts officiels.

Quelles options pour les utilisateurs de Deepin ?

La suppression de Deepin dans Fedora et openSUSE ne signifie pas la disparition du projet.

Les utilisateurs qui apprécient cet environnement de bureau disposent encore de plusieurs possibilités :

• utiliser une distribution Linux qui propose Deepin comme bureau principal
• installer Deepin depuis des dépôts tiers ou non officiels
• compiler l’environnement directement à partir du code source

Cependant, ces solutions impliquent un compromis : les paquets externes ne bénéficient pas toujours du même niveau d’audit de sécurité et de contrôle que ceux présents dans les dépôts officiels des distributions.

Une décision révélatrice de la gouvernance des distributions

L’épisode Deepin rappelle une réalité importante dans le monde Linux : la popularité ou l’esthétique d’un logiciel ne suffisent pas à garantir sa présence dans une distribution.

Les projets comme Fedora et openSUSE privilégient généralement trois critères :

• la maintenabilité à long terme
• la transparence du code
• la conformité aux audits de sécurité

Lorsque ces conditions ne sont plus réunies, même un environnement de bureau réputé pour son design peut être retiré.

Dans ce cas précis, Fedora et openSUSE ont clairement choisi une approche prudente : privilégier la sécurité et la fiabilité de leur écosystème logiciel plutôt que de maintenir un composant difficile à auditer et à maintenir.