Fedora 與 openSUSE 為何移除 Deepin 桌面環境

在 Linux 世界中，桌面環境的去留往往不只是外觀或功能問題，而是與安全審查、封裝規範與維護能力密切相關。近年 Fedora 與 openSUSE 兩個大型社群發行版相繼決定將 Deepin Desktop Environment（DDE） 從官方套件庫移除，背後原因相當類似：安全疑慮、封裝政策違規，以及上游協作不足。

以下整理整個事件的背景與影響。

Fedora 為何決定移除 Deepin

Fedora 的技術決策機構 Fedora Engineering Steering Committee（FESCo） 已決定停用並移除 Deepin 桌面相關套件。

官方討論中主要提到兩個關鍵因素：

• 持續存在的安全疑慮
• 套件維護活躍度不足

Fedora 開發者在評估過程中表示，部分 Deepin 套件維護者難以聯繫，這在社群發行版中是嚴重問題。因為安全漏洞回報、修補協作與長期維護都依賴維護者的回應速度與投入程度。

若維護與安全審查無法保持穩定合作，發行版就很難保證這些套件符合其安全標準。

openSUSE 更早的移除決定

在 Fedora 做出決定之前，openSUSE 已先行將 Deepin 從其套件庫中移除。

openSUSE 安全團隊指出，在 Deepin 的封裝過程中發現了違反發行版封裝政策的做法。具體而言，有社群打包者建立了一種變通方法，繞過 openSUSE 標準的 RPM 封裝機制，讓某些受限制資產能在未經正常安全審查的情況下被安裝。

這被視為重大政策違規，因為 openSUSE 對涉及系統功能的元件有嚴格的安全審核流程。一旦發現這類繞過機制，專案便決定將 Deepin 套件暫時移除。

當 Fedora 重新評估自己的 Deepin 套件時，自然也參考了 openSUSE 先前提出的疑慮。

D‑Bus 與 Polkit 權限相關的安全問題

除了封裝政策問題，Deepin 部分元件在安全審查中也多次被指出存在風險。

討論主要集中在兩個 Linux 系統核心機制：

• D‑Bus：Linux 桌面應用程式與系統服務之間的通訊機制
• Polkit（PolicyKit）：負責管理程式取得管理員權限的授權框架

安全審查指出，一些 Deepin 元件在透過 D‑Bus 與系統服務互動時，可能存在權限提升路徑或設計不當的情況。

其中一個長期被提及的案例是 Deepin 檔案管理器的 D‑Bus 服務。openSUSE 的安全審查已持續多年，但問題始終難以完全解決：有時修補只解決部分問題，或在後續更新中又引入新的問題。

由於 D‑Bus 服務可能讓應用程式存取系統功能，一旦設計或限制不夠嚴格，就可能造成未預期的權限存取。

上游回應速度也影響決策

另一個被兩個發行版反覆提到的因素是：與 Deepin 上游開發者的協作效率。

在過去的安全審查中，維護者曾表示：

• 有些安全問題沒有被完整分析
• 修補僅部分解決問題
• 溝通與回應速度不穩定

對 Linux 發行版來說，與上游專案的合作非常重要。若上游回應不足，發行版就很難：

• 確認漏洞是否真正修復
• 長期維護安全修補
• 持續審核安全敏感程式碼

這些因素與封裝政策違規與技術疑慮疊加後，最終導致 Deepin 被移出官方套件庫。

仍想使用 Deepin 的用戶怎麼辦

Deepin 被 Fedora 和 openSUSE 移除，並不代表這個桌面環境消失。它仍然存在於其他發行版與專案中。

如果使用者仍然喜歡 Deepin 的界面與功能，可以考慮幾種方式：

• 使用以 Deepin 為主的 Linux 發行版
• 透過第三方或非官方套件庫安裝
• 從原始碼自行編譯安裝

不過需要注意的是，非官方套件通常不會經過發行版同等級的安全審查。這意味著在系統整合與安全性方面可能存在更多風險。

這起事件反映的開源治理問題

Deepin 事件其實揭示了 Linux 發行版治理的一個核心原則：

軟體能否被收錄，不只取決於功能或人氣，也取決於安全審查、透明度與可維護性。

即使是外觀設計優秀、使用者眾多的桌面環境，如果在安全整合與維護協作方面無法符合發行版標準，也可能被移出官方套件庫。

對 Fedora 與 openSUSE 來說，這項決定反映的是一種偏向保守的安全策略：寧可減少選項，也要確保官方套件的安全與可維護性。