# Security comparison - GNOME and KDE Plasma

**URL:** https://discuss.privacyguides.net/t/security-comparison-gnome-and-kde-plasma/26656
**Category:** Questions
**Tags:** software
**Created:** 2025-04-12T23:12:19Z
**Posts:** 32

## Post 1 by @anon1614724 — 2025-04-12T23:12:19Z

Hi all,

I want to hear your opinion on security of GNOME and KDE Plasma.

I see the current recommendation on [https://www.privacyguides.org/en/os/linux-overview/#permission-controls](https://www.privacyguides.org/en/os/linux-overview/#permission-controls) and [https://privsec.dev/posts/linux/choosing-your-desktop-linux-distribution/](https://privsec.dev/posts/linux/choosing-your-desktop-linux-distribution/) highlights GNOME as the more secure option for a DE. Secureblue and Tails use it and recommend it as default.

KDE is working on fixing/implementing permission control for the screenshot portal [https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/7](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/7) so that will fix the biggest security flaw at the moment.

I’m wondering what other security features and flaws do these DE’s have and how do they compare overall?

---

## Post 2 by @HackOrSwim — 2025-04-12T23:32:05Z

The biggest issue with KDE Plasma is that global themes can, and will, run arbitrary code, and this has led to [data loss](https://discuss.kde.org/t/warning-global-themes-and-widgets-created-by-3rd-party-developers-for-plasma-can-and-will-run-arbitrary-code-you-are-encouraged-to-exercise-extreme-caution-when-using-these-products/12714) in the past. This presents an attack vector that, at the time this incident happened, most people weren’t aware existed and even made KDE developers [add a warning](https://blog.davidedmundson.co.uk/blog/kde-store-content/).

Theming may be optional, but these are flagship features of KDE and part of why it’s used, and known. Since it’s a main part of the DE, and GNOME has a more Apple-like model of customization, and so doesn’t have this attack vector, is probably one of the reasons why it’s recommended over KDE.

I like KDE a lot, I use Plasma, and I’m aware of these flaws so exercise caution accordingly, but since we have to assume not all users are the same, GNOME is the safer option (in this regard, at least). This is just my 2 cents.

---

## Post 3 by @anon1614724 — 2025-04-12T23:43:07Z

Theming is a security rabbit hole…indeed.

I hope that the newly announced Plasma Next and KDE Union projects will fix the theming in a secure way.

I suppose GNOME also has a big security problem with 3rd party extensions that act like a real time hack of the gnome-shell. I guess they are not audited because they’re not official?

---

## Post 4 by @anonymous261 — 2025-04-13T02:02:53Z

According to this GrapheneOS forum regular,  
[KDE is committed to old school and memory-unsafety, GNOME seems better but it’ll take too long to get security features across, and once COSMIC gets around, it’ll be champion](https://discuss.grapheneos.org/d/10179-problem-if-only-have-phone/14)

---

## Post 5 by @anonfox — 2025-04-13T08:59:15Z

Other than what has already been mentioned about the display isolation, GNOME implements sandboxing for their [thumbnailer](https://gitlab.gnome.org/GNOME/gnome-desktop#thumbnailing-sandboxing) and [indexer](https://gitlab.gnome.org/GNOME/localsearch#:~:text=a%20tightly%20sandboxed%20metadata%20extractor), but at least the indexer has been [exploited](https://github.blog/security/vulnerability-research/coordinated-disclosure-1-click-rce-on-gnome-cve-2023-43641/#tracker-miners-seccomp-sandbox-escape) in the past, and although they have been hardened more, I would just disable them both anyway in GNOME or KDE. Otherwise, they are a bit similar, with GNOME implementing insecure extensions, and KDE implementing insecure global themes. Not sure about the “old school” stuff since KDE adapts newer technology (see Wayland and ARM maturity for example) faster than any other DE. Also don’t know about memory safety in GNOME vs KDE. But the aspect of Qt vs GTK is interesting: Qt is maintained by a huge corporation while GTK is maintained by a few open source volunteers, so Qt might seem more secure from this aspect, but issue is that Qt5 LTS updates are proprietary paid, so the apps that still use it are technically using an end of life version, although KDE has maintained open source updates for it, but no way to make sure they fix all the vulnerabilities and bugs.  
The default keyring in GNOME appears to have some security issues.

> **[[CVE-2018-19358] Credentials located in gnome-keyring can be compromised...](https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/5)**
>
> Dear all, I figure out that login credentials, located in gnome-keyring, can be easily compromised. Linux based on Gnome basically uses ‘gnome-keyring’ as their...

> **[Locking the system does not lock the keyring (#62) · Issues · GNOME /...](https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/62)**
>
> Security philosophy doc states that one of the goals is: Hunkering down and discarding all secrets when your...

But also true for KDE

> **[KWallet Autologin: TPM, secure element, hardware features etc](https://discuss.kde.org/t/kwallet-autologin-tpm-secure-element-hardware-features-etc/15489#:~:text=Any%20app%20can%20query%20any%20password)**
>
> In reply to this post about several Plasma issues (to keep stuff sorted) To the point about: Why cant I unlock KWallet when using autologin? KWallet, the password manager storing many things wifi passwords LUKS encryption passwords probably...

> **[Using Keepassxc as gnome-keyring replacement and redirect unlock requests to...](https://github.com/keepassxreboot/keepassxc/discussions/9009#discussioncomment-6777651)**
>
> I am trying to use keepassxc as replacement for gnome-keyring. I managed to set it up that way and make it work with eg. evolution. However if keepassxc is not running already and I start evolution...

Probably better to use KeePassXC? Being written in Qt is kinda an advantage of KDE imo because I don’t want to unleash a dependency hell.  
There’s the fact that KDE uses a Chromium webview, which might be more secure than the webkit based webview of GNOME, but not sure as it only has one release that only fixes bugs and vulnerabilities every 1-3 months in distros that keep up (e.g. Fedora, not in Debian though), and it only upgrades to the latest release every 6 months, so it might very well end up being less secure, idk.  
If you use Fedora, KDE has the [advantages](https://discussion.fedoraproject.org/t/f40-selinux-confined-users-the-first-fedora-kde-to-be-productive-with-enabled-selinux-confined-user-with-restrictions/113165) of somewhat usable compatibility with selinux confined users and [not getting frozen](https://fedoraproject.org/wiki/SIGs/KDE/Update_policy) (although GNOME releases coincide with Fedora releases for the most part).

Ignoring all these technical details though, GNOME is a corp distro, so it might be more scrutinized? Plus having a lot less features, which could possibly translate to less attack surface? Not sure.

---

## Post 6 by @TheDoc — 2025-04-13T13:16:12Z

> [@anonymous261](#):
>
> KDE is committed to old school and memory-unsafety, GNOME seems better but it’ll take too long to get security features across

To be fair to KDE, I think it’s mostly developed by volunteers and switching the foundational toolkits and languages they’ve been based on for so long sounds very impractical. Carbon might be the best bet for projects who can’t switch away from C++. I’m not sure how GNOME is much better in that regard as I believe they mostly use C.

---

## Post 7 by @anon63378630 — 2025-04-13T13:57:07Z

If you use GNOME:

- disable thumbnails, it parses all files and has been exploited before
- disable search, every keystroke gets sent to dozens of programs
- disable tracker, it indexes all files and has been exploited before
- disable all extensions, they can do absolutely anything
  - especially user extensions as those are automatically updated every started and could be hijacked

- use wayland, to ensure some isolation
- use the latest version

my brace sets most of these

---

## Post 8 by @anon1614724 — 2025-04-13T14:46:00Z

> [@anonfox](#):
>
> Ignoring all these technical details though, GNOME is a corp distro, so it might be more scrutinized? Plus having a lot less features, which could possibly translate to less attack surface? Not sure.

It is logical that more eyes are watching the code because of it’s corporate usage, but I actually think GNOME has plentiful of features… they are just obfuscated and hidden by design. I suppose the code size of both DE’s is pretty similar.

---

## Post 9 by @anon1614724 — 2025-04-13T14:49:11Z

True. Both C and C++ are not memory safe languages so I suppose there’s not a lot of difference there.

KDE now uses QML for a lot of things while GNOME uses JS and TypeScript. Any difference meaningful difference there? I personally find it silly to write anything with JS but I suppose they have a reason for it :smiley:

---

## Post 10 by @anon1614724 — 2025-04-13T14:50:27Z

This looks useful! Thank you.  
I see secureblue uses some of these steps as well.

Any tips for KDE Plasma?

---

## Post 11 by @anonymous261 — 2025-04-13T14:53:34Z

Off topic, but I feel like those tips are so useful, you may want to put them in the Divested website

---

## Post 12 by @anon63378630 — 2025-04-13T15:03:10Z

> [@anonymous261](#):
>
> in the Divested website

just use brace as a whole: it does that and way more: [GitHub - divestedcg/Brace: Toolkit compatible with multiple Linux distros that allows for installation of handpicked applications, along with corresponding configs that have been tuned for reasonable privacy and security.](https://github.com/divestedcg/brace)

- combine it with firejail, fapolicyd, [real-ucode](https://github.com/divestedcg/real-ucode), and my [hardened\_malloc](https://github.com/divestedcg/rpm-hardened_malloc) package (which now [supports](https://github.com/GrapheneOS/hardened_malloc/pull/252) buffer overflow checks)
  - running brace-audit gives you the steps to do this all

---

## Post 13 by @username0990 — 2025-04-14T04:38:41Z

> [@anon63378630](#):
>
> disable search, every keystroke gets sent to dozens of programs

What exactly does this mean? Doesn’t the search feature work only to search for AppStream metadata?

---

## Post 14 by @anonfox — 2025-04-14T08:17:29Z

That thing about the actual size of codebases sounds reasonable. I remember reading that Mutter and Kwin had a similarly sized codebase (although I can’t remember where I read this).  
The corp aspect is hopefully changing with SteamOS, and Fedora KDE now has the same status as the GNOME edition. Although I don’t see this happening for RHEL any time soon.

---

## Post 15 by @anonfox — 2025-04-14T08:18:48Z

Which DE do you personally recommend for security (and privacy if relevant) if you don’t mind?

---

## Post 16 by @anonymous261 — 2025-04-14T13:41:01Z

Your question might be off topic, but I think [this video](https://divested.dev/pages/videos#brace-fedora33) would imply the answer would be Fedora.

---

## Post 17 by @Cyber-Typhoon — 2025-04-14T15:07:07Z

> [@anon63378630](#):
>
> disable thumbnails, it parses all files and has been exploited before

Is this about the Gnome Sushi? [Warning: Gnome file manager (Nautilus) can make remote requests when previewing files](https://lemmy.world/post/27398324)

I’m not sure how SecureBlue handles this but happy to see that Brace takes care of it.

---

## Post 18 by @anon63378630 — 2025-04-14T15:25:00Z

> [@Cyber-Typhoon](#):
>
> Gnome Sushi?

the one click file previewer? that should also be disabled.

> [@anonfox](#):
>
> DE do you personally recommend

Fedora with GNOME

> [@username0990](#):
>
> search feature

The search feature in the GNOME overview directly runs dozens of programs such as calculator, weather, calendar, contacts, and many others each time you type a letter.

---

## Post 19 by @anon1614724 — 2025-04-14T16:45:34Z

> [@anon63378630](#):
>
> Fedora with GNOME

How much better is GNOME than KDE in comparison?

I guess a lot of GNOME advantages go away if a user “has to” use a 3rd party extension. I’ve used default GNOME before but not many people can. I really wish COSMIC launches off as soon as possible.

---

## Post 20 by @anonfox — 2025-04-15T14:11:29Z

How is it off-topic? We’re discussing DE security, and I’d love to hear input from an expert  
Maybe you misread me as asking about distros? No worries then

---

## Post 21 by @jerm — 2025-04-15T15:09:12Z

> **[Choosing Your Desktop Linux Distribution](https://privsec.dev/posts/linux/choosing-your-desktop-linux-distribution/#desktop-environments)**
>
> Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
> Release Cycle You should choose a distribution which stays close to the stable upstream software releases, typically...

---

## Post 22 by @anonfox — 2025-04-15T15:33:13Z

XFCE and LXQt also secure privileged Wayland protocols.

> <https://github.com/secureblue/secureblue/issues/856#issue-2857039287>
>
> https://github.com/labwc/labwc/commit/f1e43762e042b5bbbdf05411303ea1a397fef722
> 
> …Both XFCE and LXQt can run on labwc, which as of the latest version secures privileged wayland protocols

---

## Post 23 by @overdrawn98901 — 2025-04-15T15:40:26Z

GMOME is the only recommended DE used in Secureblue, as it’s the only Wayland DE that has locked down specific application sharing of things like the clipboard and screenshots I believe.

EDIT: seems like KDE Plasma version 6.5. is secure now, and that Sway is making strides too.

---

## Post 24 by @anon63378630 — 2025-04-16T14:36:00Z

> **[Dangerous Arbitrary File Read Vulnerability in Yelp (CVE-2025-3155)](https://blogs.gnome.org/mcatanzaro/2025/04/15/dangerous-arbitrary-file-read-vulnerability-in-yelp-cve-2025-3155/)**
>
> I don't normally blog about particular CVEs, but Yelp CVE-2025-3155 is noteworthy because it is quite severe, public for several weeks now, and not yet fixed upstream. In short, help files can read your filesystem and execute arbitrary JavaScript...

---

## Post 25 by @RokeJulianLockhart — 2025-04-23T11:07:35Z

> GNOME and KDE are otherwise the only options. KDE is completely and forever memory unsafe (asked the Devs, never leaving Qt or even allowing Slint into core KDE apps), and GNOME is simply far behind.

@anonymous261, what are they referring to? The fact that they use C++?

---

## Post 26 by @anonymous261 — 2025-04-23T14:44:30Z

I think they are referring to that, although currently, both GNOME and KDE are not mostly written in the safest languages. Additionally, by the time GNOME could make progress on that front, COSMIC may already be out.

---

## Post 27 by @anon79740302 — 2025-04-25T16:02:05Z

A user of F42 Workstation here…

@anon63378630 While Brace is not something I would use personally, I did learn of some noteworthy settings from the repo. I also ended up uninstalling `sushi` and `yelp` after reading this topic, so thanks for all the info.

Some things I’d like to add:

- Apparently, `disable-microphone` [does nothing](https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2848) right now. Likely wouldn’t hurt to keep it disabled, though.

- Consider adding `org.gnome.calculator refresh-interval 0` to prevent GNOME Calculator from periodically fetching exchange rates, which it [does by default](https://github.com/subgraph/sgos_handbook/blob/e307251d825619928da26b6648302f945624698b/04_everyday-usage_07_subgraph_firewall.md#allowing-or-denying-connections-in-subgraph-firewall). (Anyone remember Subgraph OS?)

- The `org.gnome.desktop.lockdown` section also may be of interest.

---

## Post 28 by @anon79740302 — 2025-04-25T16:29:49Z

> [@anonfox](#):
>
> Probably better to use KeePassXC?

I want to like KeePassXC, but it’s [stuck with Qt5](https://github.com/keepassxreboot/keepassxc/issues/7774) for the [foreseeable future](https://github.com/keepassxreboot/keepassxc/pull/11651), and has yet to transition to Wayland [properly](https://github.com/keepassxreboot/keepassxc/issues/2281).

> [@](#):
>
> Being written in Qt is kinda an advantage of KDE imo because I don’t want to unleash a dependency hell.

For what it’s worth, KeePassXC is officially [available on Flathub](https://flathub.org/apps/org.keepassxc.KeePassXC). But at least on GNOME, there’s this:

> **[Clearing clipboard after timeout is broken with KeePassXC (#1241) · Issues ·...](https://gitlab.gnome.org/GNOME/mutter/-/issues/1241)**
>
> Affected version Fedora 32, mutter 3.36.2 (Wayland) Bug summary KeePassXC has a...

---

## Post 29 by @CyberOtter — 2025-04-27T08:10:14Z

For those who have installed Gnome Calculator as a Flatpak, the command is slightly different:

`flatpak run --command=gsettings org.gnome.Calculator set org.gnome.calculator refresh-interval 0`

---

## Post 30 by @anon79740302 — 2025-04-27T12:12:53Z

Alternatively, one could disable network access for Flatpak apps globally with `flatpak override --unshare=network`, and then grant this permission to apps on a case-by-case basis (e.g., `flatpak override -u --share=network org.mozilla.firefox`).

See also:

> **[Modifying default permissions | Flathub Documentation](https://docs.flathub.org/docs/for-users/permissions)**
>
> Often applications on Flathub may come with a broader set of permissions

---

## Post 31 by @RokeJulianLockhart — 2025-05-09T07:24:57Z

> [@anonymous261](#):
>
> GNOME and KDE are not mostly written in the safest languages

@anonymous261, as in, _memory_-safe? If so, at least there’s a very informal roadmap to improve this on KDE’s side:

> **[Rust - KDE Community Wiki](https://community.kde.org/index.php?title=Rust&oldid=100922#Ideas_to_use_Rust)**

There’s also a very significant debate about it over at their Discourse instance:

> **[New programming language needed for KDE?](https://discuss.kde.org/t/new-programming-language-needed-for-kde/9728/4?u=rokejulianlockhart)**
>
> Going away from C++ may encourage new contributions but may turn away current contributors just as well. KDE is a mature project and has to be created using mature tools. The only new language coming close to C++ in this aspect is Rust. It is...

---

## Post 32 by @anon57621611 — 2025-11-02T21:36:33Z

I guess this is not the case any more with KDE Plasma version 6.5.

> [@KDE Plasma 6.5 is out now with a number of highly-requested features](https://discuss.privacyguides.net/t/kde-plasma-6-5-is-out-now-with-a-number-of-highly-requested-features/32242):
>
> Another evolution is the Flatpak Permission page, which has been upgraded into a proper general desktop Application Permissions page. Here you’ll be able to configure everything properly across all your apps. And for more of the changes relevant here, see this [article](https://www.neowin.net/news/kde-plasma-65-brings-a-better-way-to-handle-app-permissions/) In Plasma 6.5, the “Flatpak Permissions” page in System Settings has expanded into a more general “Application Permissions” page. This addresses a long-standing issue with sandboxed applications. When apps running in Flatpak…
