Wayland Default DE for Real Security #168
Comments
|
How to install the KDE shell without pulling unwanted, potentially insecure dependencies? |
|
I read the debian packageIf we just install kde-plasma-desktop instead of kde-full, this on its own should care of a lot of things. This only installs the core applications. So the file manager, terminal, and some vital applications are also installed. But there is an even more minimalistic way. I read the package details and tested it in a vm. We can install the |
It pulls after having just a quick look, not a full analysis:
|
Please try this one instead. |
|
Lets see... That's better. Another quick review... Either unwanted applications or applications requiring research / hiding / reconfiguration:
Libraries I don't understand why they are pulled:
Dependencies still look massive and messy. Can we go more minimal than that?
Would any of these packages be sufficient to have a basic, minimal desktop? |
|
Hmm. Might be possible if these also pull all the Qt5 libraries, wayland and pipewire. |
|
Not to mention the more seamless and complete support for a full system mac policy. When it comes to going more minimal, I have done some tests. It is, somehow possible, but I don't think it's worth it because we have to manually install a lot of things instead of pulling them as dependencies. But if you like, we can just remove the packages you mentioned from the list and install everything else separately. I also have to say, number of packages or the size of packages are no indicators of performance or the amount of load on resources. KDE is more optimized in many ways due to being actively developed. Vulnurabilities in KDE are more likely to be discovered due to the bigger number of eyes on code and they are also much more likely to be fixed more quickly due to KDE having an active development team. These factors should also come into consideration when making the choice between KDE and Xfce. |
monsieuremre
changed the title
It's worth it. It's cleaner. We understand the dependencies better.
How? Once package declares
In theory, yes. In practice, in past KDE messed up something so KDE got unusable slow in VMs. Why, despite the big development team nobody pointing out that a huge regression is being introduced? Dunno why? Because KDE makes use of JavaScript? This would need testing theory vs practice.
You could have said this about GNOME and then...
...happened. Yes, it was discovered. Not sure how many years this exploit was possible before somebody reported it. On the other hand, no such thing happened with Xfce. It's more minimal, no crazy dependencies, pick and choose from component packages. KDE also going this route of a web service https://store.kde.org where you can press the "install" button and magic happens. |
|
I see your point. Obviously having a smaller code base comes with the benefit of a smaller attack surface. Having to rely on X11, which on its own opens way big of an attack surface than almost any javascript code out there, and is way more complicated and 'bloated'. Not to mention this complicated and big big code base which completely written without security in mind 30 years ago cannot and will not be mainted by random people. Until now redhat was the only one carrying its development, and now the abandonement process is complete. So I don't think there is a reasonable case in terms of security for Xfce, at all. When it comes to being able to run on old old hardware or being able to run on some virtual machine with severly limited resources allocated, yes, Xfce will run better. I don't think this should be a main point of consideration tho. Anything that came out in the last 10 years, anything at all, can run KDE with ease, in a VM too. So I suggest the project should not let backwards compatibility or wanting accomodate old and bad hardware limit the progress. And I'm not even suggesting those are unimportant. But what we are sacrificing is literally minimal, and the assumtions we are making are only reasonable in terms of hardware. For the really small fraction of people that want to allocate only 2 gigs of ram to a VM, it is not really unfair at this point, because you can't realistically have the good of both worlds. |
monsieuremre
changed the title
|
I want to once again call for the total and complete dropping of X11 usage for kicksecure systems. This insecure abandonware is one of the largest, if not the largest attack surface the project has. There is no time to loose. Whonix and kicksecure are small projects compared to something like debian. You are not bound to corporate or institutional stuff. You are in a position to make big changes very fast and move forward, be a pioneer for linux security. The project should be able to move quickly. The KDE option is doable, ok. I see a lack of enthusiasm on the project's end. I suggest we try other options as well to compare and see which one is more minimal or more suited for kicksecure. Can you please try installing Gnome is also a way better DE than Xfce, obviously, in terms of security, because pipewire and wayland and manpower. Also the full system apparmor policy works on gnome already on debian, with everything being enforced. So thats something to consider too. This is no being close or possible in the future thing, it works now. Lxqt could also be considered, tho not with the version on debian stable repos. So that should not be a priority. |
monsieuremre
changed the title
|
My workload doesn't allow to implement this quickly. The things I am working on there's going to be a "log entry" in either forums.kicksecure.com or forums.whonix.org (more likely for now). I'll usually post a link to or a summary to all my activities. Alternatively, check the latest Kicksecure, Whonix release announcements which contain changelogs of stuff that was done and/or git commit activity. If you see any activities which you or any programmer cannot resolve easily, quickly either, you can assume that it will take me "infinite" time as well. Could perhaps argue wrong priorities but I think it's not worth to debate priorities as per: There are no contributors either who can send tested pull requests implementing, maintaining wanted support for other desktop environments either. Elaborated here: Wayland support is planned and wanted. No advocacy for Wayland required. Work towards it was done:
I bound myself to develop software which actually works for actual users and doesn't majorly break as per: As a corporate having figured out a functional business model, developers could be hired full time to get this stuff one. But... https://www.kicksecure.com/wiki/Dev/Open_Source_Business_Models |
|
I am aware that this is more of a single man project so it wouldn't be easy to implement and maintain compicated packages. I think my wording created a rather rude impression. Sorry for that. Don't get me wrong, I am not asking for stuff. No one is entitled to some one else's voluntary work. I am just trying to contribute where I can because I like this project. Where I can't contribute directly, I try helping by suggesting. And this would be just another suggestion, which I think should be a point of focus. Because I think it would improve the security of the project massively. Because I understand. After suggesting tumbleweed as a base, I tried porting this package to rpm. For that I learned rpm packaging and stuff. I did have a fully functional rpm package at the end but it required too much work for just even one package, because a lot of stuff had to change from ground up to suit better for the new os. So I realized, this isn't easy. So I know something like this would actually take some infinite time for anyone to do alone. But I don't think this level of difficulty applies to the DE. Because I already used kicksecure on gnome and there is nothing to implement. That's why I am so easily making the suggestion to switch desktop environments. |
|
It's important to clearly distinguish between two different threat models:
A) is a much bigger concern than B). RCE is of much bigger concern than LPE. To my knowledge, X11
There has never been a vulnerability where the user simply viewed a website or clicked a link in their browser (or something similar such as an e-mail client) and then due to X11 vulnerabilities that had to remote code execution, local compromise. On the other hand,
So GNOME, KDE actually have a higher the risk of RCE. Now one could say "just install the core of GNOME or KDE without the fancy stuff". But that seems weird. On one hand we would be endorsing a new default desktop environment but on the other hand putting the breaks as in:
It seems that any theoretic advantages thanks to Wayland to harden against LPE get eaten by GNOME, KDE by the higher risk of RCE. This is not something that is likely to happen with Xfce because it does not implement such fancy stuff. GNOME on top of this does questionable decisions usability wise. They removed the systray. How to get the systray back? appindicator? Ok. How to get appindicator? Answer: https://extensions.gnome.org/extension/615/appindicator-support/ Bad answer. Not secure. But even if that is the answer... But how to automate installation of that in a derivative Linux distribution (Kicksecure)? I mean, it's great that hardening against RPE apparently is getting completed as much as it is feasible to complete that so we can now start worrying about even more advanced concepts such as hardening against LPE. After RCE has been accomplished, currently Wayland wouldn't give much advantages anyhow. As long as users use user If sudo/root access was enforced to only go through a dedicated user I would appreciate if there are other alternatives to get Wayland support. Ones that do not involve GNOME or KDE. related: Meanwhile as a stopgap perhaps the wiki should recommend to stay away from advanced X11 functionality that is vulnerable such as remote, X11 forwarding. alternative rewording by chatgpt: |
|
This is a lot. Firstly, there are a lot of understatements and overstatements here. And you are making some real big assumptions. First and the most obvious thing to point here is, a local privilege escalation can lead to remote code execution. In fact, all remote code executions have to first find ways to escalate privileges locally. Only after having elevated privileges can you run remote code. So any RCE has to involve in some way or another LPE. Is RCE worse than LPE? Yes, sure. But RCE involves LPE also. Second thing is, in your argument you reduce the security issues with X11 to countable known and distinct concepts. This is called "enumerating badness" in computer security and it is not a good way of approaching things. But even if that, your list is lacking in many ways.
Now, I see your points about GNOME. First of all, I want to mention the good. Let's be honest, GNOME is the only modern looking DE on desktop linux. Anything and everything else looks outdated. KDE looks just slightly outdated. Xfce looks straight out of 2008. It is also important that the user gets a comfortable, modern and familiar experience. Gnome is the only desktop that can provide that. That's why when anyone ever switches from windows to linux, chances are, they will use gnome. Gnome is also so maintained and organized. There have been security vulnurabilities like any project, but gnome is, and will always be, the fastest DE to identify and fix these issues. Did they make some controversial changes? Yes. Is not having a systray bad? Yes. Is installing a billion extensions bad? Absolutely. But I support not installing any extensions. So if I get a vote ever, I will defend using gnome on kicksecure. Also consider that gnome can be used whilst fully confined with the mac policies from @roddhjav. These are literally ready to pack and use. This provides protection from literally most of the vulnurabilities.
This would be an option to look into if our base wasn't debian. Lxqt now has decent support for wayland for most stuff. Not complete but really getting there, and I would say almost there. It is minimal also. Budgie and Mint have plans to switch to wayland in the foreseeable future. Literally everything other than Xfce will support wayland anyway. Most of everything will 'only' support wayland. I hope Xfce makes the leap as well, but unlikely it seems. And I know that it is not fair game because Xfce is only a small group of people, and developing a wayland compositor is significantly more work than just making an X11 desktop. if we are to use debian as the base, we can't just have wayland with other DE's, not until Debian 14 at least. So we have to make the choice right here and now. If we were on a rolling release, we could start experimenting with Lxqt right this day, identify if anything goes wrong. Those would be fixed along the way anyway. |
|
More way towards Wayland to consider:
What's the problem with LXQt in Debian? |
|
Local Privilege Escalation (LPE) and Remote Code Execution (RCE): It's not accurate to claim that all RCEs necessarily involve LPE. LPE and RCE are distinct types of vulnerabilities. LPE is about gaining higher privileges on a system where the attacker already has access, while RCE is about remotely executing code on a target system. While it's possible for an RCE exploit to also involve LPE (for example, first exploiting a remote service and then escalating privileges to gain more control), it's not a requirement. There are cases where RCE does not require LPE, especially if the remotely exploited service already has high privileges. Regarding X11 vulnerabilities, it's important to assess each CVE individually, as not all vulnerabilities in X11 would necessarily lead to RCE. Has there ever been a case of Remote Code Execution (RCE) in X11 where just visiting a website through a browser or a similar action led to RCE? I think no. One such vulnerability is CVE-2023-6377, found in the xorg-server, where querying or changing XKB button actions, such as moving from a touchpad to a mouse, could result in out-of-bounds memory reads and writes. This flaw may allow for local privilege escalation or possible remote code execution in cases where X11 forwarding is involved. However, this doesn't directly imply that visiting a website would trigger the vulnerability. Additionally, a well-documented exploitation of X11's unauthenticated access vulnerability, identified as CVE-1999-0526, illustrates the potential for a range of malicious activities. This includes capturing keystrokes, screenshots, and even establishing a reverse shell, which indicates a degree of remote code execution capability. However, the exploitation of this vulnerability also doesn't inherently relate to web browsing activities but rather involves an attacker connecting directly to the X11 server, which is accepting connections from any internet source. This would require specific conditions such as an improperly configured X11 server with unauthenticated access. In conclusion, while certain vulnerabilities in X11 could theoretically lead to RCE, these instances are not typically associated with the simple act of visiting a website with a browser. The exploitation of these vulnerabilities often requires more direct interaction with the X11 server under specific conditions. X11 is ~40 years battle tested. And lots of detail security research has been done. Yet, no security researcher ever managed to find an X11 RCE that does not involve X11 forwarding or other fancy stuff such as X11 over TCP / networking. The GNOME 1 click RCE (remote code execution). in my opinion is far worse than X11. GNOME established a code path from the browser, where a simple click has lead to an RCE exploitable libcue (CD layout parsing of all the things) vulnerability. GNOME, KDE apparently aren't security-prioritizing projects, neither have good security "by accident" through minimalism (maybe Xfce). Even after the libcue 1 click GNOME RCE I am not aware of any culture change at GNOME. The reaction was to patch libcue but as far as I know not attack surface reduction, i.e. avoid clicking in a browser resulting in libcue C unsafe memory CD layout parsing. vote: (It's a going to be Whonix survey but even contributors exclusively to Kicksecure because Whonix is based on it and benefits from it.) So you're welcome to work on the community survey draft as well. And for humor... Local Privilege Escalation (LPE) |
The problem is that is one thousand years behind upstream. And this is not a problem that will magically be fixed with the next debian stable release. Because for one even brand new debian stable releases do not have the latest upstream versions most of the time. It mostly a version some months before the release where the debian guys it is time to freeze. This is very relevant for something like LXQt, especially since we want to use it for wayland. Although it is 'works' with wayland, a lot of stuff is still not ready. See here. It is actively being developed. Many things are being worked on. Ideally switching to lxqt on whonix would go like this:
We can't do any of this if we use the debian repo version. If not changing the base, we should (if this is reasonably possible of course) package stuff ourselves. Kicksecure packages Hardened Malloc from the tarball. I don't think packaging minimal desktop components should be much more different. |
Debian trixie LXQt is currently 1.3 (which already has Wayland support supposedly) while upstream is 1.4. Since Debian bookworm wasn't released long ago and freeze is still far way, chances are that a fewer version will make its way into Debian trixie.
I don't think I can do this.
That's a rather simple repository from a packaging perspective. Just one not too complex Makefile. Just 1 resulting binary file. Just only 1 package. Packaging a DE is a much bigger task. LXQt has 48 repositories on github. Also forking packages that Debian already has will add extra complexity. So instead would be a better use of time to contribute the updated version to Debian directly. |
|
Also I would like to underline once again, that the gnome desktop can be protected with a really fine-grained mac policy to its fullest, including but not limited to all its component services and daemons, using apparmor.d. If kicksecure was gnome, such vulnurabilities as you often mention would not be effective, because Because mac policies are not broad, they are fine grained, and by extensions provide a really, really and I mean really significant protection against many exploits. Having gnome also has this advantage. And I think this one is just as important as native wayland support. Take a look at the |
|
While apparmor.de is great it's not a substitute to for other security layers such as attack surface reduction. The main goal must be to not be exposed to superfluous memory unsafe code parsing. A) Xfce without apparmor.d:
B) Xfce with apparmor.d:
C) GNOME without apparmor.d:
D) GNOME with apparmor.d:
In conclusion, cases A) and B) are still preferable over C) and D). Therefore there's no real alternative to attack surface reduction. |
|
I see your point, and it is a weak one I have to say. I think there is very bias playing a role here. You keep mentioning the CVE that allows 1 click arbitrary code execution in gnome. Less than a year before that vulnurability was published, Xfce has also had a same type CVE, that allows 1 click arbitrary code execution. They both received a severity rating of 8.8. But the Xfce is probably much worse if you wonder, because other organizations have assigned higher severity scores, for example this one has 9.8 Pretending Xfce is immune to vulnurabilities because the code base is smaller is very misleading. This would only be true if Xfce and Gnome were projects of the same scale. But they are not. And this is not just due to their size or the number of people in their teams. Because of its vastly smaller number of users, and even more vastly smaller number of people among them who actually examine the code, Xfce will never be on Gnome's level at fixing security issues. So a more accurate table would be: Xfce without apparmor.d:
Xfce with apparmor.d:
Gnome without apparmor.d:
Gnome with apparmor.d:
|
|
Based on https://lists.debian.org/debian-security-announce/2022/msg00132.html (the most comprehensive explanation about this vulnerability that I could find) Xfce CVE-2022-32278 does not seem to be a 1 click remote code execution (RCE) directly a chain from the browser to malware executing system on the victim computer. Seems like that Xfce vulnerability didn't receive as much attention as the GNOME vulnerability which had a nice blog post by github explaining it in detail.
After writing this I also consulted ChatGPT which explains how this vulnerability could be abused better than I could: And then used ChatGPT to compare the two vulnerabilities which makes my point and saves me a lot of typing: GNOME and KDE also come with additional bad surprises, not important, attack surface increasing and privacy intrusive features such as GeoClue. Privacy issues: If one installs gnome-clocks one also gets geoclue-2.0. And even if all of this is resolved, it's not possible to skip parts. Building a Linux distribution is similar like building a car. There are some absolutely required components such as needing a chassis and the wheels. A question such as "how to add a systray to GNOME" is similar to lacking a wheel. It's a most basic feature and a blocker if not known how to do that. Without resolving that question, it's not possible to proceed. Clicking buttons is inappropriate for a Linux distribution. Therefore now collecting these blockers, questions here: Due to these unresolved issues, porting to GNOME seems less likely. The most likely approaches towards Wayland currently that I can see currently: |
Please provide another method of viewing this convo without having to log in using an open-ai account. The vulnurabilities are not the same obviously. I am making the point that xfce is not protected automatically from exploits and this is not something specific to gnome. They are both CVE's with the same score, less than a year apart. If anything, one cna make the argument that gnome is more in the position to tackle these issues faster. Also I want to mention that, yes, in fact, wayland alone would more than make up for this hypothetical difference. And as I said, this not just because X11 is really insecure, which is absolutley is, but also it is unmaintained abandonware that has a massive code base. If reducing attack surface is important, ditching X11 is the biggest step towards reducing the unnecessary code base, which also happens to be unmaintained in this case. Linux Mint just came out with their new release, first time with wayland support on cinnamon. It is pretty solid I have to say. Budgie is also switching to wayland, they even made it clear from the beginning that there won't be a X11 session in the future, which is the logical choise because no one is maintaining it. All desktops will sooner or later be wayland, at least those that are not in epic denial. And by the looks, Xfce is soon to be either dead, or they somehow magically change their approach. This is just the hard reality. I am in support of gnome rather than lxqt if given the choice, because they are going to be the first one to drop x11 completely and have a massive reduction in their code. The others will follow, no doubt, as they are already making it clear. But I think not having X11 available by any means at all on the desktop is something desirable for a security distribution. That being said, having wayland default is obviously still infinetely better than sticking with X11. Lxqt is absolutely usable as of now with wayland. So I will support that if that is the choice you are willing the consider. But as I mentioned previously check this page. There are like merges from just weeks ago. Some new stuff was fixed just 2 days ago. These guys are making progress, on the go, actively, and big time. Wayland support is incrementally getting even better and better and the missing pieces are being filled. While Xfce is still taking its time to switch to GTK 4 after a millenium, these guys, as a Qt based desktop, will switch to Qt6 very soon, probably right after KDE does, which says a lot about how the two projects are maintained. One is maintained actively. One is, for whatever reason, maybe their own or not, is de facto in just maintain-mode. So this is absolutely also a big reason to Xfce. Because if Xfce was up to the standards of a secure and well maintained DE, we will not be having this conversation to switch desktops, we would just wait for Xfce to go wayland. So Lxqt is absolutely a desktop I would like to support, but we can't realistically do it on debian without delaying our switch for another century where we will literally be the last one to do the switch for good. It is still better than xfce. So if you say lxqt, I say yes. If you say hyperland even, I say yes. If you say anything wayland, I support your motion. When it comes to Wayfire, it is just a wayland compositor, not a DE. So I don't know why you have that as an option there. |
|
Wrong link. My mistake. Link updated just now in above post. Viewing is possible without account. I wouldn't make needing an account mandatory for viewing. Also available on web archive in case the live version doesn't live forever. Vulnerability score: Seems arbitrary coming from some calculator that is based on arbitrarily assigned values. Might be useful to know "i should really upgrade" but here it's comparing an RCE with an LPE. Not really fair to get same same score. Wayfire: Not a complete DE but a custom DE based on Wayfire could be developed. That would presumably be just a collection of packages that includes Wayfire, wf-shell and any other Wayland compatible package that could presumably be taken from other Wayland capable desktop environments. For example if a display settings (screen resolution) GUI tools is required and LXQt has one, that could be combined. LXQt is more likely worth a proof of concept port to test if it's suitable or Wayfire (less likely because learning curve might be higher, might require more work). GNOME has just too many blockers mentioned in above wiki link. |
|
Well Lxqt already supports using wayfire as the compositor if that means anything. They are also testing stuff and were considering switching to it. I am not sure about the status now. But anyway, Lxqt is a really nice project, and it makes good progress. I would be full on board with this if we weren't debian and didn't have to wait a life time. |
|
This is a very important discussion. I also think that the switch to Wayland is necessary given the myriad of benefits over X11. The key question is then of timing, when do we switch? Do we do it ASAP and expose ourselves to potential unknown Wayland vulnerabilities? Or do we do it after carefully watching and evaluating the transition across all major DEs while currently being exposed X11’s downsides? The right approach is no doubt somewhere between these extremes. However, I am not going to claim to know where exactly the optimal balance exists. Thinking in terms of the extremes, currently in my opinion a conservative approach would be to wait and not begin the migration today. As you highlight, every DE that wants to remain relevant is porting to Wayland. Good. Let them switch and I am sure as they go from X11 -> minimum working product -> … -> beta -> ... -> Wayland-only, a vast array of bugs and issues that are currently inconceivable will be discovered and fixed. Right now only KDE and Gnome are at a stage I would personally consider relatively ‘complete’. I am not an expert on the composition of these organisations but I would be very surprised if there are cumulative >100 developers that are deeply involved in the switch to Wayland and understand its inner workings. Compare this to the probably thousands of developers that have worked with X11 over the centuries. The more unique eyes in different organisations that are working on developing Wayland DEs the better. This situation makes me currently lean more towards holding off transitioning today. While Wayland was designed from the ground-up with security in mind, a lot of the current focus is on compatibility which is to be expected. Once large portions of the Linux ecosystem begin moving, I think its only then we will get true insight on how secure it truly is as people will also begin creating exploits targeting Wayland specifically. As a side note, I also think that the relatively small amount of dependencies Xfce has is major plus. Overall, I do not want to repeat arguments from the extensive discussion above and so in terms of my defined extremes, should we switch to Wayland? Absolutely! Should we switch today? No, ‘better the devil you know than the devil you don't’. I think a good approach would be to have monthly or quarterly reviews on this subject examining characteristics both of you have thoroughly mentioned. Keeping track of things such as progress of DEs, CVEs, and dependencies would be essential. |
The answer to that is as soon as possible. Wayland is stable. Gnome won't have X11 at all (like this year literally). Budgie won't have X11 at all. Mint even, won't have X11 at all. Everyone literally is making the switch and they are fast. Look the mint team had no wayland session and now they have a funcitoning wayland session like in lightning speed. If there is a will there is a way. They have to do switch, so they are doing it, like everyone else. Tough luck we are stuck with the only DE that does not have a clear plan to switch. Switch to wayland has already happened for the most part for most people.
Compare this to zeroes of developers that are maintaining X11 as of now. X11 has been in maintenance mode for a long long time anyway. And now, it is literally unmaintained. And while we are at it I think we should also compare the hundreds of developers working on gnome vs the ones of developers working on Xfce. I am not defending anything, but this logic automatically leads to this conclusion.
This comment reads from a really long time ago. It isn't that year anymore. If you use gnome, wayland is as stable as it gets. Nowadays you don't even use Xwayland almost at all, a lot of stuff is native.
Yes of course. Then let's switch to lxqt. It is also minimal. But I don't see any reason to wait for longer. We are already behind the adaptation curve by a long shot. |
Next needed:
|
|
When I find the time: I will test lxqt on debian sid. Will test usage and some other details like dependencies. My guess is that this will be usable (from their wayland support wiki page) and very minimal as they often claim to be the minimal qt desktop. I will then test the same on debian stable. If I'm not mistaken, debian stable has lxqt qith wayland support, but the versions tha came after it fixed and added a lot of new stuff. My guess is that it will be somewhat passable with some noticeable problems. |
|
https://twitter.com/lxqt_project/status/1766417095519047757 It seems the desktop component of lxqt is now wayland ready. |
|
Good news, LXQt 2.0.0 has been released and should have "full Wayland support". |
Any update? |
and others
As the title says. I think whonix maintainers in the forum have discarded the idea of moving back to kde too quickly. Moreover, I find most all of the arguments to be for the most part unfounded. KDE being bloated or heavy for Whonix is just not true. KDE used to be 'heavier' when both Qubes and Whonix were using it. It is now much more optimized. Xorg is unironically massively more bloated than wayland. All the 'bloat' is not part of the DE. We do not have to install everything. Just install the shell and we are done.
And I want to make this clear, I propose we only install the shell. Not even the terminal, not the file manager, nothing from the debian repositories but the shell, and let me explain why. But before that, I want to recap once again why xfce severly slows whonix down.
So at the very least, before I make the argument for KDE, we should all more or less agree on this: Xfce bad. At least for security.
Now my argument for KDE.
Switching to flatpak defaults would normally be a seperate suggestion of mine, but yeah consider that extra. Getting the latest KeePassXC officially from the developers or getting the latest Thunderbird officially and directly from Mozilla is a huge leap in security. Of course I trust the debian team to do the packaging well and port security issues. But they can't be as good at porting security fixing than directly having them fixed from the developers. Can't be as fast. Anyway this is a seperate topic, for now disregard. Only consider what relates KDE.
The text was updated successfully, but these errors were encountered: