Not surprised about this. There comes a point where not having enough resources to deal with “security reports” is quite frankly BS. A security culture is very important, regardless of whatever language barriers the Deepin maintainers may have. Actions do speak better than words at the end of the day.
The experience with Deepin software and its upstream during the code reviews that we performed has not been the best. More than once, security issues we reported have been replaced by new security issues. Other times, upstream did not invest the effort to fully analyze the issues we reported and fixed them insufficiently. Generally the communication with upstream proved difficult, maybe also due to the language barrier. While upstream stated at times that they don’t have enough resources to deal with security reports, which is worrying enough, the design and implementation of Deepin D-Bus components often changed radically in unrelated ways. This makes the security assessment of Deepin components a moving target. Building trust towards Deepin components has thus been extremely difficult over the years.
The history of Deepin code reviews clearly shows that upstream is lacking security culture, and the same classes of security issues keep appearing. Although we only looked at a small fraction of the code Deepin consists of, we found security issues nearly every time we looked at one of its components. Based on these experiences, we expect further security issues to linger in the rest of the Deepin code that does not stick out, as the D-Bus services do (as they run with raised privileges). Given the experiences we have gathered with Deepin D-Bus services, we consider it likely that they break user isolation. These components are certainly not fit for multi-user systems; even on single user systems they will be weakening defense-in-depth significantly.
I’m glad to see OpenSUSE being serious about security and reviewing DE’s package seriously. How do other distros like Fedora, Arch, Mint, etc handle this ?
Fedora has underwent some controversy regarding the fact that they have a separate Flatpak repo that is not Flathub, and some say that Fedora Flatpaks are broken and insecure compared to Flathub ones. Still, they’ve generally had security practices positive enough for secureblue to use Fedora.
This might be off topic, but this security comparison is also leading me to wonder how openSUSE’s automated tested rolling releases compare to Fedora’s semi-rolling releases in security, and if a fully released openSUSE Aeon could have been a better base for secureblue than Silverblue