Die Linux‑Distributionen Fedora und openSUSE haben unabhängig voneinander entschieden, die Deepin Desktop Environment (DDE) aus ihren offiziellen Software‑Repositories zu entfernen. Obwohl die Entscheidungen zeitlich nicht exakt zusammenfielen, lagen ihnen ähnliche Gründe zugrunde: Sicherheitsbedenken, Verstöße gegen Paketierungsrichtlinien und Schwierigkeiten bei Wartung sowie Zusammenarbeit mit den Upstream‑Entwicklern.
Der Fall zeigt gut, wie streng große Distributionen inzwischen bei Themen wie Sicherheitsprüfung, Paketqualität und Wartbarkeit vorgehen.
Warum Fedora Deepin entfernt hat
Bei Fedora fällt die Entscheidung über technische Richtlinien und Paketpolitik dem Fedora Engineering Steering Committee (FESCo) zu. Dieses Gremium beschloss, die Deepin‑Pakete aus Fedora zu retiren und aus der Distribution zu entfernen.![]()
Zwei Hauptgründe spielten dabei eine Rolle:
- Anhaltende Sicherheitsbedenken rund um mehrere Deepin‑Komponenten
- Geringe Wartungsaktivität der Paketbetreuer, wodurch Updates und Sicherheitsfixes schwer sicherzustellen waren
Während der Überprüfung berichteten Fedora‑Entwickler außerdem, dass einige der zuständigen Maintainer nur schwer erreichbar waren. Für Community‑Distributionen ist das ein ernstes Problem: Wenn Maintainer nicht reagieren, verzögern sich Sicherheitsfixes und Fehlerbehebungen – und das Risiko für Nutzer steigt.![]()
Aus Sicht des Fedora‑Projekts ließ sich daher nicht mehr garantieren, dass die Deepin‑Pakete langfristig den Sicherheits‑ und Wartungsstandards der Distribution entsprechen.
Die Rolle der früheren Entscheidung von openSUSE
Fedora traf seine Entscheidung nicht im luftleeren Raum. openSUSE hatte Deepin bereits zuvor aus seinen Repositories entfernt, nachdem bei der Paketierung ein Verstoß gegen die Sicherheitsrichtlinien entdeckt worden war.![]()
![]()
Nach Angaben des openSUSE‑Security‑Teams hatte ein Community‑Paketbetreuer einen Workaround implementiert, der die üblichen RPM‑Mechanismen umging. Dadurch konnten bestimmte eingeschränkte Komponenten installiert werden, ohne den vorgesehenen Sicherheits‑Review‑Prozess auszulösen.![]()
![]()
Für openSUSE war das ein schwerwiegendes Problem. Die Distribution setzt bewusst auf strikte Paketierungsregeln, damit sicherheitsrelevante Komponenten vor der Aufnahme gründlich geprüft werden. Wird dieser Prozess umgangen, untergräbt das das Sicherheitsmodell der gesamten Distribution.
In der Folge entschied das Projekt, Deepin vorerst vollständig aus seinen Repositories zu entfernen.![]()
Technische Sicherheitsbedenken: D‑Bus und Privilegien
Neben den Paketierungsproblemen wurden auch konkrete technische Sicherheitsfragen diskutiert.
Mehrere Berichte verwiesen auf mögliche Risiken in Deepin‑Komponenten, insbesondere in Bereichen, die mit Systemdiensten interagieren. Dazu gehörten:
- D‑Bus‑Dienste, über die Anwendungen mit Systemprozessen kommunizieren
- Polkit (PolicyKit), das steuert, wann Programme administrative Rechte erhalten dürfen
Bei solchen Komponenten können Designfehler oder unzureichende Zugriffsbeschränkungen dazu führen, dass Anwendungen ungewollt höhere Systemrechte erhalten.![]()
![]()
Ein Beispiel ist die D‑Bus‑Schnittstelle des Deepin‑Dateimanagers, deren Sicherheitsprüfung laut openSUSE‑Maintainers über Jahre hinweg nicht endgültig abgeschlossen werden konnte. Kritiker berichteten, dass einige gemeldete Probleme nur teilweise behoben wurden oder bei späteren Änderungen neue Risiken entstanden.![]()
Schwierigkeiten mit der Upstream‑Zusammenarbeit
Ein weiterer wichtiger Faktor war die Kommunikation mit den ursprünglichen Deepin‑Entwicklern.
Maintainer bei openSUSE berichteten, dass Sicherheitsprobleme teilweise nur unvollständig behoben wurden und die Zusammenarbeit mit Upstream nicht immer reibungslos verlief.![]()
Für Distributionen ist diese Kooperation entscheidend. Ohne aktive Upstream‑Maintainer wird es schwierig,
- sicherheitskritischen Code zu überprüfen,
- bestätigte Schwachstellen zuverlässig zu beheben,
- und langfristig stabile Pakete zu pflegen.
Wenn gleichzeitig Sicherheitsfragen offen bleiben und die Paketierung gegen Richtlinien verstößt, steigt für Distributionen der Druck, die betreffende Software zu entfernen.
Was das für Nutzer bedeutet
Wichtig ist: Deepin selbst ist nicht verschwunden. Entfernt wurden lediglich die Pakete aus den offiziellen Fedora‑ und openSUSE‑Repositories.
Wer die Desktop‑Umgebung weiterhin nutzen möchte, hat mehrere Möglichkeiten:
- eine Linux‑Distribution verwenden, die Deepin offiziell unterstützt
- Deepin aus inoffiziellen oder Drittanbieter‑Repositories installieren
- die Komponenten selbst aus Quellcode bauen
Allerdings gibt es dabei einen entscheidenden Unterschied: Pakete außerhalb der offiziellen Distributionen durchlaufen in der Regel nicht denselben strengen Sicherheits‑ und Paketierungsprozess, den Projekte wie Fedora oder openSUSE verlangen.
Ein typisches Beispiel für Distribution‑Governance
Der Fall Deepin zeigt ein Grundprinzip vieler Linux‑Distributionen: Ob Software enthalten ist, hängt nicht nur von Beliebtheit oder Funktionen ab. Entscheidend sind auch
- Wartbarkeit
- Transparenz des Codes
- Einhaltung von Paketierungs‑ und Sicherheitsrichtlinien
Selbst eine optisch beliebte Desktop‑Umgebung kann deshalb aus offiziellen Repositories verschwinden, wenn Distributionen ihre Integrität und Sicherheit nicht mehr gewährleisten können.
Für Fedora und openSUSE war die Entfernung von Deepin letztlich eine konservative Sicherheitsentscheidung – mit klarer Priorität für überprüfbare Paketierung, stabile Wartung und zuverlässige Zusammenarbeit mit Upstream‑Entwicklern.
