I had no idea that (open)SUSE was so security minded in their packaging. It makes sense in retrospec. It sucks they didn’t catch this earlier, but this response makes me happy to use tumbleweed
Barring Arch, and boutique distros, other distros normally have even better packaging standards than opensuse. By far.
No they don’t. OpenSUSE, especially tumbleweed, is way more security-focused than other distros.
It’s a very low-trust default install, and it takes some work to get things through the firewall. Compare that to Fedora where every port above 2025 is open by default.
This is what vertical integration between distros and GUIs often leads to. This could be completely innocuous from Deepin’s end, because that’s just how they made it work in Deepin because they have vertical integration on their own stack. However, It’s completely bad form.
In general Deepin seems to adopt a lot of commercial software industry practices in building its tools, which I’m sympathetic to on some level, but it’s very obvious that the Linux community is not going to accept default-on telemetry. They should have known better after the CNZZ incident.
Wasn’t vertical integration, was done by packager.
We don’t believe that the openSUSE Deepin packager acted with bad intent when he implemented the “license agreement” dialog to bypass our whitelisting restrictions. The dialog itself makes the security concerns we have transparent, so this does not happen in a sneaky way, at least not towards users. It was not discussed with us, however, and it violates openSUSE packaging policies.
Right, but what I’m saying the design to need these things was likely based on Deepin running their own distro. They don’t have to consider the security guidelines of other distros like KDE or Gnome, XFCE or Enlightenment would.
It needed those things brought in through the back door because the code was a steaming pile of shit security wise and would have been rejected at the front door.
In January 2025, during routine reviews, we stumbled upon the deepin-feature-enable package, which was introduced on 2021-04-27 without consulting us or even informing us.
Damm
Why wasn’t this catched by previous routine reviews?
It seems to me that the offending dialog would only be triggered if you did a full fresh install. During the previous iteration of the testing, they probably had a VM somewhere with it installed; since the underlying packages were already present, the dialog would never have popped up.
That is quite a while, lol. To be fair though, there are an insane amount of lines in most packages. Quietly adding a brief line in a seemingly innocent features package is like hiding a needle in a haystack.
Its easy to overlook things when you have a pile of packages to review during every routine. Its especially true if they missed it the first time, since its easier to review changes in a package rather than go through the whole thing again.
A needle in a tumbleweed, if you will. :p
Yeah, it’s crazy it was hiding this long but I see this as a win that they dealt with it so swiftly and show they take their package security seriously.
Yeah, it really speaks volumes about the devs. It means that no matter how innocent the package may be or how long its been there, they still pick through it all multiple times to make sure their users are safe and happy.
But RIP Deepin users. Tbh though, I’ve been hanging around Linux forums a while and still have yet to see someone who actually daily drives Deepin, lol.
