Warum Fedora und openSUSE Deepin aus ihren Repositories entfernt haben

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.