5.9 更新，deepin社区发布了回应与改进措施：
为解决历史遗留问题并构建长效安全机制，我们已启动以下整改措施，全程公开进度，接受社区监督：
一、限期修复历史安全问题（5 月底前完成）
- 重启安全审查：全面审查过去 openSUSE 所反馈的安全问题及处理情况，确保所有安全问题已经得到解决。对于仍未彻底解决的问题，我们会制定详细的修复计划。
- 深度扫描潜在风险：除了针对历史安全问题进行修复，我们将对可能涉及类似安全隐患的项目进行全面审查（如deepin-daemon 等相关项目），确保所有潜在风险得到排除。
- 进度透明化公示：我们会在Github 项目页面（https://github.com/orgs/linuxdeepin/projects/246）上跟踪并公开工作进展，确保每个问题的处理情况都能得到及时反馈。
二、建立技术专责与流程规范
- 设立安全技术专责：deepin 桌面环境中多个安全问题都与 D-Bus 和 Polkit 等技术相关，这些问题的出现涉及到多个项目和开发人员的共性错误，这是我们不应忽视的教训。故我们设立D-Bus及Polkit技术专责审查人，后续负责对所有相关配置文件的变更和新增进行严格审查。
- 减少特权服务依赖：在后续开发中，我们将尽量避免在 deepin 桌面环境中使用特权服务（例如以 root 权限运行的 D-Bus 服务），始终将安全性作为首要考虑，确保系统的安全性不被妥协。
三、强化安全响应与协作机制
- 设立安全响应中心：加强安全专属邮箱security@deepin.org的响应资源，所有安全问题将由安全团队统一与下游社区及打包者进行对接，避免普通开发者在处理安全问题时的疏漏或不专业行为。
- 优化打包协作支持：为避免再次出现开源社区打包者因打包合规性问题而被迫提出类似deepin-feature-enable的方案，我们后续将与所有下游发行版DDE的维护人员进行积极沟通，了解现有维护中遇到的困难，从代码层面提供支持，使维护者在遇到问题时能使用更好的解决方案。
四、提升代码模块化与可审计性
为了方便做安全审计，我们将更加注重代码的模块化，允许部分功能或模块为可选，将deepin桌面环境的核心功能与扩展功能分开，避免产生强耦合。
感谢与致歉
感谢openSUSE团队多年来对deepin桌面环境的支持和对其安全问题的持续监督，同时也感谢openSUSE的deepin桌面环境维护者的持续打包贡献。deepin社区始终将安全与用户体验置于首位，此次事件更深刻地警醒了我们的安全意识，我们承诺未来将以更开放的协作、更严格的标准、更快速的响应，与全球开发者及合作伙伴携手，构建安全可信的桌面生态。
最后，再次向支持deepin桌面环境的用户、开发者及合作伙伴致歉。deepin社区将以此次事件为契机，全面提升技术实力与社区责任感，为全球用户提供更安全、稳定的开源桌面环境。
附：
SUSE 安全团队宣布， 因 Deepin 社区贡献者违反打包政策，已从 openSUSE 发行版移除 Deepin 桌面 (DDE)。
![]()
公告原文如下：
Deepin 桌面环境（DDE）是 Deepin Linux 发行版的一部分。它注重可用性、精致的图形界面以及支持中文。它也适用于其他一些 Linux 发行版，openSUSE 就是其中之一。
最近我们注意到 openSUSE 中 Deepin 桌面环境的打包存在政策违规行为。为了规避安全审查要求，Deepin 社区打包者实现了一个变通方法，绕过了常规的 RPM 打包机制来安装受限资源。
由于这一违规行为，并且考虑到我们与 Deepin 代码审查的复杂历史，我们将暂时从 openSUSE 发行版中移除 Deepin 桌面包。
![]()
SUSE 安全团队对此举的说明如下：
2025 年 1 月，在例行审查期间，我们发现了deepin-feature-enable包，该包于 2021-04-27 引入，而在此过程中我们既没有被咨询，也没有被告知。
这个看似无害的包实现了一个“许可协议对话框”，基本上解释了 SUSE 安全团队对 Deepin 桌面环境的安全性存在疑虑，但为了正确使用 Deepin 桌面环境，某些组件仍需安装。
![]()
因此，如果用户不关心安全性，则应接受“许可”。如果用户接受，则deepin-daemon-dbus和deepin-daemon-polkit包中的 tarball 会自动提取缺失的 D-Bus 配置文件和 Polkit 策略到系统目录中。许可文本还包含一个提示，建议手动安装deepin-file-manager-dbus和deepin-file-manager-polkit包，并运行一个脚本来侧载 Deepin 文件管理器 D-Bus 组件所需的进一步配置文件。
对于最终用户来说，这实际上意味着在安装 Deepin 模板时，只需输入一次“y”即可选择激活 SUSE 安全团队未接受的可疑安全组件。
考虑到多年来发生的众多审查，频率和活动有所下降，我们错误地认为，到如今 Deepin D-Bus 组件的大部分已经在我们批准后进入 openSUSE:Factory （除了某些可选工具包）。相反，我们发现 deepin-daemon 包中的核心组件从未提交给我们审查，而是被偷偷摸摸地引入了 openSUSE。
自 2019 年以来，Deepin 文件管理器一直存在审查漏洞，而软件包仍未达到令人满意的状态。让用户能够运行脚本来激活有问题的组件，不如通过定制的“许可对话框”自动完成，但这仍然是一种不干净且可疑的方法。
SUSE 团队对此事发表了自己的看法：
在我们进行代码审查的过程中，Deepin 软件及其上游的体验并不理想。我们报告的安全问题不止一次被新的安全问题所取代。有时，上游并没有投入精力去充分分析我们报告的问题，并且修复不足。
总体而言，与上游的沟通非常困难，或许也是语言障碍的原因。虽然上游有时会表示他们没有足够的资源来处理安全报告（这已经足够令人担忧），但 Deepin D-Bus 组件的设计和实现经常以不相关的方式发生根本性的变化。这使得 Deepin 组件的安全评估变得像一个不断变化的目标。因此，多年来建立对 Deepin 组件的信任变得极其困难。
Deepin 代码审查的历史清楚地表明，上游缺乏安全文化，同类安全问题不断出现。尽管我们只审查了 Deepin 代码的一小部分，但几乎每次审查其组件时都会发现安全问题。基于这些经验，我们预计 Deepin 代码中其他不太明显的部分可能还存在安全问题，而 D-Bus 服务则不然（因为它们以提升的权限运行）。鉴于我们在 Deepin D-Bus 服务方面的经验，我们认为它们很可能破坏了用户隔离。这些组件显然不适用于多用户系统；即使在单用户系统上，它们也会显著削弱纵深防御。
发现该 deepin-feature-enable软件包绕过安全白名单的行为标志着我们对 Deepin 评估的一个转折点。我们认为 openSUSE Deepin 软件包构建者在实施“许可协议”对话框以绕过我们的白名单限制时并非出于恶意。该对话框本身将我们所关注的安全问题透明化，因此这种情况并非以偷偷摸摸的方式发生，至少不会对用户造成影响。
然而，我们并未就此进行讨论，这违反了 openSUSE 的软件包政策。除了安全方面，这还会影响一般的软件包质量保证：deepin-feature-enable例如，软件包安装的 D-Bus 配置文件和 Polkit 策略对于软件包管理器来说是未知的，并且在软件包删除后不会被清除。我们认为此类绕过行为是不可接受的。
综合以上因素，我们决定将 Deepin 桌面从 openSUSE Tumbleweed 以及未来的 Leap 16.0 版本中彻底移除。在 openSUSE Leap 15.6 中，我们 deepin-feature-enable只会移除有问题的软件包。
鉴于 Deepin 桌面拥有大量用户，这是一个艰难的决定。我们坚信 openSUSE 中的 Deepin 打包和安全评估需要重新开始，最好能引入一些新人，帮助他们完善 Deepin 软件包，与 Deepin 上游建立联系，并密切关注错误修复，从而避免无谓的后续审核，浪费我们的时间。在这样的新环境下，我们愿意重新逐一审查所有敏感的 Deepin 组件。
当然，这个过程需要时间，我们作为安全团队的能力也有限。鉴于Deepin项目的规模，我们也希望其他Linux发行版和（安全）社区能够加入我们，共同努力与Deepin上游构建更好的安全文化。
SUSE团队还梳理了具体的时间线：
![]()
完整内容查看：https://security.opensuse.org/2025/05/07/deepin-desktop-removal.html
