Main reasons:
-
Bypass of the openSUSE Packaging Policy via a “License Agreement” Dialog
-
Problematic review history.
They must invested a crazy amount of time working on that giant write-up.
1 Like
Indeed.
But extraordinary claims need extraordinary back-up of facts, I suppose, so I think I understand why they produced this text.
1 Like
Very interesting given other history with Deepin. I love their interface, but I’m not sure I’m that keen on the security policies.
1 Like
I ‘auditioned’ about 20 pdf reader yesterday since it’s been ten years with evince and I’m tiring of it…
…really about 19 just weren’t my style including mupdf, qpdf, zathura, papers, foxit, the list goes on and on and on. Just flat out dismissed them out of hand.
But I went absolutely ga-ga over deepin-reader. Loved it.
Terminal code output was mostly in Chinese…then did some reading about security stuff like ^^ and the ‘house’ apps like reader calling home and I could not tell the FUD from the truth.
It’s my favorite PDF reader by far…and I’m afraid to use it. 
. Oh my luck!
Deepin devs do seem to understand the UI and what looks good.
I agree–they have a keen eye. It’s all pretty. I wonder if there are strings attached to that, though.
We’re probably being overly cautious..but I’m just not sure either 
1 Like
all i could find was a CVE at NIST from late 2023 (https://nvd.nist.gov/vuln/detail/CVE-2023-50254).
“Deepin Linux’s default document reader deepin-reader software suffers from a serious vulnerability in versions prior to 6.0.7 due to a design flaw that leads to remote command execution via crafted docx document. This is a file overwrite vulnerability. Remote code execution (RCE) can be achieved by overwriting files like .bash_rc, .bash_login, etc. RCE will be triggered when the user opens the terminal. Version 6.0.7 contains a patch for the issue.”
No other CVE’s for the pdf viewer. May install it. Combing thru yay -Ss pdf viewer right now for any I missed yesterday.
Not my thread so no more hijack .
Deepin has always been a smattering of different toolkits and was also historically aimed specifically at an Ubuntu base - its development often making assumptions with that in mind. Some of the dbus comments on it being weirdly strung together and changes suddenly/radically seem to be examples of these kinds of development standards.
For these reasons alone I never thought it worth any serious consideration. Security in general was somewhat of a question but not really investigated. All being all the less relevant if the thing is too junky to be taken seriously in the first place (and maybe there has been less attention to such details for the same reasons).
that was Suse’s conclusion in that article. Not malicious, per se, but erratic and amateurish code in important places,
The original post at [1] was updated on 14 may 2025 with a reaction of Deepin:
“After publication of this report we received an email response from Deepin upstream and they also published a blog post on the topic which contains similar content. They outline an action plan on how to improve the security stance of Deepin and also intend to solve any unfixed issues we reported by the end of May 2025.”
edit: updated the title of this post to signal Deepin’s reaction
Deepin gave themselves 4 days at present (2 weeks as of your 14 May date), to fix that long Suse list of sec flaws and try to get back into Suse’s DE stable.
Be impressive if they pull that off.