[Others] openSUSE 再次评估 DDE 的桌面组件安全性,结果依然令人失望
Tofloor
poster avatar
mozixun
Moderator
2026-05-15 14:07
Author

原文链接: https://security.opensuse.org/2026/04/20/winter-spotlight.html#section-deepin

审核组件是: https://github.com/linuxdeepin/dde-daemon 版本: 6.1.66, 但实际最新版本到6.1.89

image.png

总结的中文翻译: 由于安全问题反复出现,上游解决这些问题所需的时间较长,且深度操作系统项目中缺乏正式的安全修复工作流程,我们已停止为在深度操作系统中发现的问题分配CVE(Common Vulnerabilities and Exposures,通用漏洞披露)。我们认为,由于安全问题往往很快就会被其他安全问题所取代,因此进一步的CVE工作意义不大,大多只是徒增噪音。总体而言,在深度操作系统上游的安全文化得到改善之前,我们不建议使用深度操作系统的组件。

到目前为止,我们也在以较低的优先级处理深度操作系统(Deepin)的审核请求,因为多年的努力仍未取得令人满意的结果,我们更愿意将资源投入到其他更有前景的软件包中。

Reply Favorite View the author
All Replies
1 / 2
To page
avatar
pzm9012
Moderator
2026-05-15 14:15
#1

doubt

Reply View the author
avatar
mozixun
Moderator
2026-05-15 14:17
#2

OpenSUSE指出他们审核的是6.1.66, 而Github上最新版本已经至6.1.89, 最新提交:

https://github.com/linuxdeepin/dde-daemon/commits/master/

目前情况: The openSUSE Deepin packager informed us that there are also fixes for these issues available by now, but we did not get around to verify them yet.

如果没有精力不能及时更新桌面组件的话, 个人更建议用OBS开第三方源而非直接推入别的发行版仓库给其它发行版仓库维护者增加负担

Reply View the author
avatar
你总说是我的错
deepin
2026-05-15 14:20
#3

爱用不用,不必惯着 openSUSE

Reply View the author
avatar
mozixun
Moderator
2026-05-15 14:21
#4
你总说是我的错

爱用不用,不必惯着 openSUSE

如果没有精力不能及时更新桌面组件的话, 个人更建议用OBS开第三方源而非直接推入别的发行版仓库给其它发行版仓库维护者增加负担

现在 @罐子 维护的Debian 13适配源就是OBS开三方源的

Reply View the author
avatar
罐子
Moderator
2026-05-15 14:56
#5

没必要进发行版仓库。

我现在就很烦,debian13的官方源里面有一些dde组件或者dde应用等,很有干扰

,应该单独一个组件仓库。

不应该进发行版主仓库里。

Reply View the author
avatar
mozixun
Moderator
2026-05-15 15:03
#6
罐子

没必要进发行版仓库。

我现在就很烦,debian13的官方源里面有一些dde组件或者dde应用等,很有干扰

,应该单独一个组件仓库。

不应该进发行版主仓库里。

其实你维护的那几个包也直接覆盖了发行版仓库的旧版本了吧 )

Reply View the author
avatar
zccrs
deepin
2026-05-15 15:35
#7

文章里提到的这些问题,在 6.1.89 版本的确都已经解决了。但是,一方面新包到suse那边肯定有延迟,二方面是suse那边也不是只在乎这些已知问题是否已经解决,主要是看还有没有更多问题,是不是能达到suse的标准,把标准内的问题都查漏补缺全都解决的差不多了。后者的要求是非常高。

Reply View the author
avatar
罐子
Moderator
2026-05-15 16:09
#8
mozixun

其实你维护的那几个包也直接覆盖了发行版仓库的旧版本了吧 )

是,但是如果我漏了这个包就会被依赖关系把旧包安装进来。

Reply View the author
avatar
erdospj
deepin
2026-05-15 16:51
#9
你总说是我的错

爱用不用,不必惯着 openSUSE

看出西人的傲慢,走我们自己的路。

Reply View the author
avatar
deepin
2026-05-15 17:58
#10

只能说明linux桌面发行版,在根上并不是完全互相兼容,有自己的利益。

Reply View the author
avatar
神末shenmo
deepin
Spark-App
Q&A Team
2026-05-15 18:09
#11
罐子

没必要进发行版仓库。

我现在就很烦,debian13的官方源里面有一些dde组件或者dde应用等,很有干扰

,应该单独一个组件仓库。

不应该进发行版主仓库里。

所以GXDE最后没跟SID

debian那边很烦的是,做debian dtk移植的人只管能不能编译通过,不怎么管应用能不能正常运行

Reply View the author
avatar
新手小白
deepin
2026-05-15 20:09
#12

希望dde相关的包早日滚出Arch官方源。dde在别的发行版连正常运行都有问题

proud

Reply View the author
avatar
流星追月
deepin
2026-05-15 20:29
#13

摆明进入踢皮球环节了......

解决不了问题,就先把提出问题的人解决了,这样是最省事的。

有人的地方就有江湖,有江湖就有恩怨。

Reply View the author
avatar
米饭虚拟机-nana版
deepin
2026-05-15 20:34
#14
你总说是我的错

爱用不用,不必惯着 openSUSE

opensuse算个集贸。

修复bug,提高流畅度,好好搞生态才是正事

Reply View the author
avatar
chmod700
deepin
2026-05-15 21:45
#15

自己用就行了,dde这个流畅度,以及正式版发行一年了论坛还屡见反馈各种浅性的bug的稳定性来说,就别去祸害别的发行版了。deepin要是能放开其他DE的安装限制,彻底卸载系统中的dde组件,流畅度和稳定性肯定上一个大台阶,但那又完全丧失了deepin特色了。另外我还有个疑问,用别的发行版的真有用dde的需求?

Reply View the author
avatar
mozixun
Moderator
2026-05-15 21:51
#16
chmod700

自己用就行了,dde这个流畅度,以及正式版发行一年了论坛还屡见反馈各种浅性的bug的稳定性来说,就别去祸害别的发行版了。deepin要是能放开其他DE的安装限制,彻底卸载系统中的dde组件,流畅度和稳定性肯定上一个大台阶,但那又完全丧失了deepin特色了。另外我还有个疑问,用别的发行版的真有用dde的需求?

DDE 高度依赖Qt 6.8, 在6.10/6.11+上会因为一些Qt bug/API变更带来一些问题

然后, 为什么别的发行版你用KDE/GNOME感觉没啥问题, 只要你去翻一下Ubuntu 26.04源中为了维护了KDE Plasma 6.6在debian/patches目录下打了多少补丁就知道了

Reply View the author
avatar
chmod700
deepin
2026-05-15 22:40
#17
mozixun

DDE 高度依赖Qt 6.8, 在6.10/6.11+上会因为一些Qt bug/API变更带来一些问题

然后, 为什么别的发行版你用KDE/GNOME感觉没啥问题, 只要你去翻一下Ubuntu 26.04源中为了维护了KDE Plasma 6.6在debian/patches目录下打了多少补丁就知道了

DDE和KDE都严重依赖QT,用QT开发的软件UI普遍很丑,尤其是那个标题栏,UI我觉得GTK设计语言挺好的。除了丑这一点外,QT开发的软件运行效率也不高,运行起来感觉就像是Wine跑windows软件。这两个就是我不用KDE的原因。不知道这两个DE问题多跟QT有没有关系

Reply View the author
avatar
mozixun
Moderator
2026-05-15 23:06
#18
chmod700

DDE和KDE都严重依赖QT,用QT开发的软件UI普遍很丑,尤其是那个标题栏,UI我觉得GTK设计语言挺好的。除了丑这一点外,QT开发的软件运行效率也不高,运行起来感觉就像是Wine跑windows软件。这两个就是我不用KDE的原因。不知道这两个DE问题多跟QT有没有关系

如果你说你喜欢GTK4大额头, 那这只是你个人的审美

你当然可以把B站所有喷DDE大额头的用户拉来论证你不喜欢是对的, 但也只代表你这个群体不喜欢, 你不喜欢不代表其他人不喜欢, 其他人喜欢DDE大额头并不代表你的厌恶是错的

其次

QT开发的软件运行效率也不高

那真得去试一下Freedreno驱动去跑GTK4应用了,让你体验到什么叫都开Turnip驱动了libadwaita动画掉帧也就跟隔壁用EGL/OpenGL ES的KDE Framework一桌。你的电脑核显很强, 有逼近Radeon 680M的性能感知不到 (同样, 我电脑AMD Radeon 780M核显对于GTK4和KDE Framework的动画响应性能差距也感觉不到) , 不代表对于Qualcomm 骁龙855+这样的低性能平台对于GTK4和KDE特色Qt不能论证GTK4动画响应也就跟Qt应用动画响应一桌

最后, QT软件如果效率不高为什么大量嵌入式UI使用LVGL/Qt技术栈而不是用GTK4? Qt跟GTK都是GPL许可证家族下的跨平台框架, 在有KDE Free Qt的今天两者许可证上已经没什么问题

最后, 我举的KDE的例子不代表给GNOME和GTK的补丁就少了,具体去翻mutter和gnome-shell和一堆gir库等看看有多少补丁就行, 这还是不考虑连treeland都实现Xwayland应用分数缩放都不需要超分辨率就能实现Xwayland应用原生缩放时GNOME 50仍然只能超分再整数倍缩小引来根本无法用补丁修复的前提下

Reply View the author
avatar
chmod700
deepin
2026-05-16 00:07
#19

1,基于qt的程序,在我看来就像是win7毛玻璃时代,还在用xp时代的UI。这个审美问题我就不讨论了。

2,我没有arm设备,测试不了,也不发表意见了。

3,至于大家为啥更倾向于在嵌入式用qt而非GTK,这个是因为qt的跨平台属性而非性能吧?

4,你说的哪个发行版针对gnome和mutter打了大量补丁,恰恰说明了问题。有这么多的问题,大家还愿意为它打补丁,debian,ubuntu,fedora,rhel等等主流发行版还用它作为默认桌面,恰恰说明了它的可靠性。换言之,就算它问题很多,因为用户基础大,有这么多主流发行商使用它,因此解决方案也很多,可以反哺回GNOME。

目前我对GNOME唯一不满的是它的默认文件管理器Nautilus稳定性欠佳,在加载一个有众多svg文件的文件夹(比如打开一个有几千个图标的图标主题文件夹)时,容易内存占用飙升,甚至导致Nautilus假死。

Reply View the author
avatar
mozixun
Moderator
2026-05-16 00:27
#20
chmod700

1,基于qt的程序,在我看来就像是win7毛玻璃时代,还在用xp时代的UI。这个审美问题我就不讨论了。

2,我没有arm设备,测试不了,也不发表意见了。

3,至于大家为啥更倾向于在嵌入式用qt而非GTK,这个是因为qt的跨平台属性而非性能吧?

4,你说的哪个发行版针对gnome和mutter打了大量补丁,恰恰说明了问题。有这么多的问题,大家还愿意为它打补丁,debian,ubuntu,fedora,rhel等等主流发行版还用它作为默认桌面,恰恰说明了它的可靠性。换言之,就算它问题很多,因为用户基础大,有这么多主流发行商使用它,因此解决方案也很多,可以反哺回GNOME。

目前我对GNOME唯一不满的是它的默认文件管理器Nautilus稳定性欠佳,在加载一个有众多svg文件的文件夹(比如打开一个有几千个图标的图标主题文件夹)时,容易内存占用飙升,甚至导致Nautilus假死。

因此解决方案也很多,可以反哺回GNOME

到目前为止我没有看到任何发行版修复了GNOME构史的分数缩放实现变成Kwin 5.27+的缩放方案

在我看来就像是win7毛玻璃时代,还在用xp时代的UI

treeland上的模糊算法已经实现亚克力效果, 不是Qt无法实现只是KDE的审美问题

然后Valve默认使用KDE Plasma而非GNOME, Cannonical面向个人计算机终端的KFocus使用Kubuntu而非Ubuntu, Fedora KDE Edition升级到和WorkStation一桌的原因不必多说吧, 在正常Linux服务器运维上对于桌面的需求本来就很小, GNOME现在仍然是Ubuntu默认桌面只是因为GNOME 3时期表现优异以至于Flutter还在拿GTK3当画板的历史惯性而已

image.png

image.png

image.png

最后嵌入式设备的UI为什么要跨平台, 嵌入式设备UI实现不追求低占用去追求跨平台意义何在?

Reply View the author
1 / 2
To page