Wayland Default DE for Real Security

[monsieuremre]

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.

• Xfce is now officially the only 'major' DE that does not have a plan to switch to wayland for good. They say they would try stuff, but that's it. It is not even certain that they will switch at all. Even Cinnamon has given a date now. Budgie, Mate, they are all switching, they have plans, they have dates. Stuff like Lxqt are already almost completely switched. Xfce is an outlier here. And this is expected. They for some reason agreed not to use wlroots or libmutter. That means they kinda have to develop their own compositor, which we all know is not possible with the little funding Xfce has. If they do not decide to suddenly base on wlroots, Xfce will never have wayland.
• Xfce is lags behind, massively. On everything. The desktop looks really, really, but I mean really outdated. Normally this is not as important but you have to keep in mind, compelling to the average user is something you probably want.
• It is really a shame whonix still unironically ships with xorg as default.
• The only reason this is still just passable is whonix designed to be run on a VM. But Kicksecure is planned to be a regular distro. That means, xorg gotta go, really. True and real.
• Xfce is small. You tell on the Whonix website that you base on Debian, and one of the reasons for that is that there is a good chance in 10 years Debian is still going to be around. Do you know what not might be around in 10 years? Xfce. And by 'might', I mean they won't definetely be around, if they don't catch the pace in switching to wayland.

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.

• KDE e.V. is a well-established and well-funded non-profit organization based in Germany. They are not some random project.
• KDE is customizable. It is fast. It is optimized. It can be as simple and minimalistic, if not more minimalistic, than xfce on demand.
• KDE has a well functioning wayland compositor. Which is to be the default.
• KDE provides almost all of their software as flatpaks. I know this might not mean much to you. But this is the reason why I suggested we install the shell from the debian repository and literally stop there. For everything else KDE, let's use the flatpak. Cut out the middle man. Get our software directly from KDE developers as they intend. Much faster bug and security fixes. It is also possible to vastly increase the flatpak sandboxing provided by bubblewrap with some overrides. The file manager, the terminal, the literally everything, as a flatpak. This is the only case I would support flatpaks. Because we get the software directly from the developers, and we get bubblewrap default. Can be further hardened too. Want a secure system? It won't get more secure than getting your software directly from the developer with all the security fixes, in a sandboxed environment. (This clause is optional of course)

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.

[adrelanos]

How to install the KDE shell without pulling unwanted, potentially insecure dependencies?

[monsieuremre]

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 plasma-desktop package. It installs the base desktop. Does not even install the file manager or the terminal. I think this has to be minimalistic enough.

[adrelanos]

sudo apt install --simulate --no-install-recommends kde-plasma-desktop

...
Inst libdebuginfod-common (0.188-2.1 Debian:12.2/stable [all])
Inst libkf5configqml5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst libkf5idletime5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst libkf5screen-data (4:5.27.5-2 Debian:12.2/stable [all])
Inst libxcb-dpms0 (1.15-1 Debian:12.2/stable [amd64])
Inst libkf5screendpms8 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst liblayershellqtinterface5 (5.27.5-2 Debian:12.2/stable [amd64])
Inst libkscreenlocker5 (5.27.5-2 Debian:12.2/stable [amd64])
Inst install-info (6.8-6+b1 Debian:12.2/stable [amd64])
Conf install-info (6.8-6+b1 Debian:12.2/stable [amd64])
Inst libkf5balooengine5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst libkf5filemetadata-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5filemetadata3 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5baloo5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst baloo-kf5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst breeze-cursor-theme (4:5.27.5-2 Debian:12.2/stable [all])
Inst breeze-icon-theme (4:5.103.0-1 Debian:12.2/stable [all])
Inst libkf5style5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst kde-style-breeze (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkdecorations2private10 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkdecorations2-5v5 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst kwin-style-breeze (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst breeze (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libdolphinvcs5 (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst libsquashfuse0 (0.1.105-1 Debian:12.2/stable [amd64])
Inst libxdgutilsbasedir1.0.1 (1.0.1-3.1 Debian:12.2/stable [amd64])
Inst libxdgutilsdesktopentry1.0.1 (1.0.1-3.1 Debian:12.2/stable [amd64])
Inst libappimage1.0abi1 (1.0.4-5-1 Debian:12.2/stable [amd64])
Inst libepub0 (0.2.2-6 Debian:12.2/stable [amd64])
Inst libpoppler-qt5-1 (22.12.0-2+b1 Debian:12.2/stable [amd64])
Inst libqmobipocket2 (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst libkf5filemetadata-bin (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5baloowidgets5 (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst libpackagekitqt5-1 (1.1.1-1 Debian:12.2/stable [amd64])
Inst libphonon4qt5-data (4:4.11.1-4 Debian:12.2/stable [all])
Inst libphonon4qt5-4 (4:4.11.1-4 Debian:12.2/stable [amd64])
Inst phonon4qt5-backend-vlc (0.11.3-1 Debian:12.2/stable [amd64])
Inst phonon4qt5 (4:4.11.1-4 Debian:12.2/stable [amd64])
Inst dolphin (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-syntaxhighlighting (5.103.0-3 Debian:12.2/stable [amd64])
Inst drkonqi (5.27.5-2 Debian:12.2/stable [amd64])
Inst libappstreamqt2 (0.16.1-2 Debian:12.2/stable [amd64])
Inst frameworkintegration (5.103.0-1 Debian:12.2/stable [amd64])
Inst libdebuginfod1 (0.188-2.1 Debian:12.2/stable [amd64])
Inst libipt2 (2.0.5-1 Debian:12.2/stable [amd64])
Inst gdb-minimal (13.1-3 Debian:12.2/stable [amd64])
Inst hwdata (0.368-1 Debian:12.2/stable [all])
Inst kdialog (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst kfind (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst libkf5konq6 (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst konqueror (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst kwrite (4:22.12.3-1 Debian:12.2/stable [amd64])
Inst kde-baseapps (4:22.12.3+5.142 Debian:12.2/stable [amd64])
Inst kde-cli-tools-data (4:5.27.5.1-2 Debian:12.2/stable [all])
Inst libkf5su-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5su5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5su-bin (5.103.0-1 Debian:12.2/stable [amd64])
Inst kde-cli-tools (4:5.27.5.1-2 Debian:12.2/stable [amd64])
Inst layer-shell-qt (5.27.5-2 Debian:12.2/stable [amd64])
Inst oxygen-sounds (4:5.27.5-2 Debian:12.2/stable [all])
Inst plasma-desktop-data (4:5.27.5-2 Debian:12.2/stable [all])
Inst qml-module-org-kde-sonnet (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-qqc2desktopstyle (5.103.0-1 Debian:12.2/stable [amd64])
Inst plasma-integration (5.27.5-2 Debian:12.2/stable [amd64])
Inst kwin-data (4:5.27.5-3 Debian:12.2/stable [all])
Inst libqt5multimediaquick5 (5.15.8-2 Debian:12.2/stable [amd64])
Inst qml-module-qtmultimedia (5.15.8-2 Debian:12.2/stable [amd64])
Inst libkwinglutils14 (4:5.27.5-3 Debian:12.2/stable [amd64])
Inst libkwineffects14 (4:5.27.5-3 Debian:12.2/stable [amd64])
Inst libxcb-cursor0 (0.1.4-1 Debian:12.2/stable [amd64])
Inst kwin-common (4:5.27.5-3 Debian:12.2/stable [amd64])
Inst milou (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst plasma-workspace-data (4:5.27.5-2+deb12u1 Debian:12.2/stable [all])
Inst qml-module-org-kde-draganddrop (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-kcoreaddons (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5holidays-data (1:5.103.0-1 Debian:12.2/stable [all])
Inst libkf5holidays5 (1:5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-kholidays (1:5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-quickcharts (5.103.0-1 Debian:12.2/stable [amd64])
Inst libksysguardsystemstats1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libksysguardsensors1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libksysguardsensorfaces1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-ksysguard (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-kwindowsystem (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-solid (5.103.0-1 Debian:12.2/stable [amd64])
Inst libcolorcorrect5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libgps28 (3.22-4.1+b1 Debian:12.2/stable [amd64])
Inst libkf5activitiesstats1 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5kexiv2-15.0.0 (22.12.3-1 Debian:12.2/stable [amd64])
Inst libkf5networkmanagerqt6 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5people-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5peoplebackend5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5people5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5peoplewidgets5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkfontinst5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libkfontinstui5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libkpipewire5 (5.27.5-3 Debian:12.2/stable [amd64])
Inst libksgrd9 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkf5screen8 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkf5screen-bin (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libnotificationmanager1 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libplasma-geolocation-interface5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libqalculate-data (4.5.1-1 Debian:12.2/stable [all])
Inst libqalculate22 (4.5.1-1 Debian:12.2/stable [amd64])
Inst libtaskmanager6abi1 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libweather-ion7 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst plasma-workspace (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst polkit-kde-agent-1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkf5kdelibs4support-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5kdelibs4support5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libscim8v5 (1.4.18+git20211204-0.1 Debian:12.2/stable [amd64])
Inst plasma-desktop (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst kde-plasma-desktop (5:142 Debian:12.2/stable [amd64])
...

It pulls after having just a quick look, not a full analysis:

• konqueror, a browser
• baloo-kf5. Baloo is a file indexer. Something like https://github.blog/2023-10-09-coordinated-disclosure-1-click-rce-on-gnome-cve-2023-43641/ waiting to happen.
• drkonqi, a crash handler, I don't know if sending a core dump is just 1 click away or encouraged.
• dolphin, a file manager.

[monsieuremre]

But there is an even more minimalistic way. I read the package details and tested it in a vm. We can install the plasma-desktop package. It installs the base desktop. Does not even install the file manager or the terminal. I think this has to be minimalistic enough.

Please try this one instead.

sudo apt install --simulate --no-install-recommends plasma-desktop

[adrelanos]

Lets see...

Inst libdebuginfod-common (0.188-2.1 Debian:12.2/stable [all])
Inst libkf5configqml5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst libkf5idletime5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst libkf5screen-data (4:5.27.5-2 Debian:12.2/stable [all])
Inst libxcb-dpms0 (1.15-1 Debian:12.2/stable [amd64])
Inst libkf5screendpms8 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst liblayershellqtinterface5 (5.27.5-2 Debian:12.2/stable [amd64])
Inst libkscreenlocker5 (5.27.5-2 Debian:12.2/stable [amd64])
Inst breeze-cursor-theme (4:5.27.5-2 Debian:12.2/stable [all])
Inst breeze-icon-theme (4:5.103.0-1 Debian:12.2/stable [all])
Inst libkf5style5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst kde-style-breeze (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkdecorations2private10 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkdecorations2-5v5 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst kwin-style-breeze (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst breeze (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-syntaxhighlighting (5.103.0-3 Debian:12.2/stable [amd64])
Inst drkonqi (5.27.5-2 Debian:12.2/stable [amd64])
Inst libappstreamqt2 (0.16.1-2 Debian:12.2/stable [amd64])
Inst libpackagekitqt5-1 (1.1.1-1 Debian:12.2/stable [amd64])
Inst frameworkintegration (5.103.0-1 Debian:12.2/stable [amd64])
Inst libdebuginfod1 (0.188-2.1 Debian:12.2/stable [amd64])
Inst libipt2 (2.0.5-1 Debian:12.2/stable [amd64])
Inst gdb-minimal (13.1-3 Debian:12.2/stable [amd64])
Inst hwdata (0.368-1 Debian:12.2/stable [all])
Inst kde-cli-tools-data (4:5.27.5.1-2 Debian:12.2/stable [all])
Inst libkf5su-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5su5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5su-bin (5.103.0-1 Debian:12.2/stable [amd64])
Inst kde-cli-tools (4:5.27.5.1-2 Debian:12.2/stable [amd64])
Inst kwin-data (4:5.27.5-3 Debian:12.2/stable [all])
Inst libqt5multimediaquick5 (5.15.8-2 Debian:12.2/stable [amd64])
Inst qml-module-qtmultimedia (5.15.8-2 Debian:12.2/stable [amd64])
Inst libkwinglutils14 (4:5.27.5-3 Debian:12.2/stable [amd64])
Inst libkwineffects14 (4:5.27.5-3 Debian:12.2/stable [amd64])
Inst libxcb-cursor0 (0.1.4-1 Debian:12.2/stable [amd64])
Inst kwin-common (4:5.27.5-3 Debian:12.2/stable [amd64])
Inst layer-shell-qt (5.27.5-2 Debian:12.2/stable [amd64])
Inst libcolorcorrect5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libgps28 (3.22-4.1+b1 Debian:12.2/stable [amd64])
Inst libkf5activitiesstats1 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5balooengine5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst libkf5filemetadata-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5filemetadata3 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5baloo5 (5.103.0-2 Debian:12.2/stable [amd64])
Inst libkf5holidays-data (1:5.103.0-1 Debian:12.2/stable [all])
Inst libkf5holidays5 (1:5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5kdelibs4support-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5kdelibs4support5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5kexiv2-15.0.0 (22.12.3-1 Debian:12.2/stable [amd64])
Inst libkf5networkmanagerqt6 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5people-data (5.103.0-1 Debian:12.2/stable [all])
Inst libkf5peoplebackend5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5people5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5peoplewidgets5 (5.103.0-1 Debian:12.2/stable [amd64])
Inst libkf5screen8 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkf5screen-bin (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libkfontinst5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libkfontinstui5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libkpipewire5 (5.27.5-3 Debian:12.2/stable [amd64])
Inst libksgrd9 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libksysguardsystemstats1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libksysguardsensors1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libksysguardsensorfaces1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst libnotificationmanager1 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libphonon4qt5-data (4:4.11.1-4 Debian:12.2/stable [all])
Inst libphonon4qt5-4 (4:4.11.1-4 Debian:12.2/stable [amd64])
Inst libplasma-geolocation-interface5 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libqalculate-data (4.5.1-1 Debian:12.2/stable [all])
Inst libqalculate22 (4.5.1-1 Debian:12.2/stable [amd64])
Inst libscim8v5 (1.4.18+git20211204-0.1 Debian:12.2/stable [amd64])
Inst libtaskmanager6abi1 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst libweather-ion7 (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst milou (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst oxygen-sounds (4:5.27.5-2 Debian:12.2/stable [all])
Inst phonon4qt5-backend-vlc (0.11.3-1 Debian:12.2/stable [amd64])
Inst phonon4qt5 (4:4.11.1-4 Debian:12.2/stable [amd64])
Inst plasma-desktop-data (4:5.27.5-2 Debian:12.2/stable [all])
Inst qml-module-org-kde-sonnet (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-qqc2desktopstyle (5.103.0-1 Debian:12.2/stable [amd64])
Inst plasma-integration (5.27.5-2 Debian:12.2/stable [amd64])
Inst plasma-workspace-data (4:5.27.5-2+deb12u1 Debian:12.2/stable [all])
Inst qml-module-org-kde-draganddrop (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-kcoreaddons (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-kholidays (1:5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-quickcharts (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-ksysguard (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-kwindowsystem (5.103.0-1 Debian:12.2/stable [amd64])
Inst qml-module-org-kde-solid (5.103.0-1 Debian:12.2/stable [amd64])
Inst plasma-workspace (4:5.27.5-2+deb12u1 Debian:12.2/stable [amd64])
Inst polkit-kde-agent-1 (4:5.27.5-2 Debian:12.2/stable [amd64])
Inst plasma-desktop (4:5.27.5-2 Debian:12.2/stable [amd64])

That's better.

Another quick review...

Either unwanted applications or applications requiring research / hiding / reconfiguration:

• drkonqi, a crash handler, I don't know if sending a core dump is just 1 click away or encouraged.
• gdb-minimal, a debugger

Libraries I don't understand why they are pulled:

• libkf5baloo5, libkf5baloo5 (file indexer related)
• libdebuginfod1 - "Debuginfod is a service providing debug information over an HTTP API."
• qml-module-org-kde-syntaxhighlighting
• qml-module-qtmultimedia
• qml-module-org-kde-kholidays
• qml-module-org-kde-quickcharts
• libweather-ion7
• qml-module-org-kde-sonnet

Dependencies still look massive and messy.

Can we go more minimal than that?

• plasma-workspace / plasma-workspace-wayland
• kwin-wayland

Would any of these packages be sufficient to have a basic, minimal desktop?

[monsieuremre]

Hmm. Might be possible if these also pull all the Qt5 libraries, wayland and pipewire.

[monsieuremre]

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.

[adrelanos]

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.

It's worth it. It's cleaner. We understand the dependencies better.

But if you like, we can just remove the packages you mentioned from the list

How? Once package declares Depends: ... it's hard to remove such dependencies without breaking APT or without understanding the package, patching it by removing the dependency on the source code level (not just the Depends: line) and rebuilding it.

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.

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.

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.

You could have said this about GNOME and then...

Simply clicking a link on a website has resulted in remote code execution. https://github.blog/2023-10-09-coordinated-disclosure-1-click-rce-on-gnome-cve-2023-43641/

...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.

[monsieuremre]

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]

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-core and report what you find undesirable?

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.

[adrelanos]

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: https://www.kicksecure.com/wiki/Reporting_Bugs#Software_Development_Cycle

There are no contributors either who can send tested pull requests implementing, maintaining wanted support for other desktop environments either. Elaborated here: https://www.kicksecure.com/wiki/Other_Desktop_Environments

Wayland support is planned and wanted. No advocacy for Wayland required. Work towards it was done: https://forums.whonix.org/t/make-sure-whonix-tools-support-wayland/12324

You are not bound to corporate or institutional stuff.

I bound myself to develop software which actually works for actual users and doesn't majorly break as per: https://www.kicksecure.com/wiki/Stable_Version_User_Experience

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

[monsieuremre]

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.

[adrelanos]

It's important to clearly distinguish between two different threat models:

• A) remote code execution (RCE);
• B) local privilege escalation (LPE) (malicious code already running locally)

A) is a much bigger concern than B). RCE is of much bigger concern than LPE.

To my knowledge, X11

• 1) has security issues when doing fancy things such as using it over a remote (X11 forwarding), perhaps when using VNC (didn't research that yet) and
• 2) issues with local privilege escalation.
• It however has no issues with remote code execution when simply using X11 locally.

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,

• GNOME:
  • Has been vulnerable to 1 click RCE (remote code execution).
• KDE:
  • KDE is going into a similar direction with https://store.kde.org as in "magic click in browser to install things from a website".

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:

• "but see all of these warnings what not do"
• "You need an extension? Ehrm, no. You better avoid the fancy https://extensions.gnome.org/extension/615/appindicator-support/ and need to get it somehow from packages.debian.org or without magic clicks in the browser."

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 user to run sudo something it is easy for locally running malware to LPE to root.

If sudo/root access was enforced to only go through a dedicated user admin (and not user user) (something like https://www.kicksecure.com/wiki/Dev/boot_modes) or other serious sandboxing then yes, Wayland would close some LPE holes. Since implementing these things is hard and will take time, Wayland isn't a priority for me.

I would appreciate if there are other alternatives to get Wayland support. Ones that do not involve GNOME or KDE.

related: https://forums.whonix.org/t/port-to-wayland/17380

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: https://chat.openai.com/share/f0aa04be-9e73-42da-b33c-7eea762faf41

[monsieuremre]

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.

• The most significant problem with X11 that it is not maintained by anyone. Until recently, Red Hat was literally the only entity maintaining X11. With them gone, there are no de facto maintainers. X11's code base so bloated and big and old, it is already really hard to be community maintained, and now with all the community gone, there is no one willing to maintain X11. X11 code base receives no commits. It is abandonware. This is the main big argument for Wayland.
• As mentioned, X11 code base is so big. If we want simplicity, X11 would not be the place to look for it.
• X11 code base older than me, older than the linux kernel, also older than you probably. It is made for a system that fitting in 1980's standards. Yes it was updated or whatever, but anything on top of the base is just patches and bandaids that make it work more modernly, but in its core, it is still old. There was never a ground up update. And this does matter, because the was majority of security issues and practices did not exist back then, so the base was not written with any security in mind.
• X11 also has issues with RCE. If you look at the CVE's X11 received, most any of them can theoretically also be used to execute remote code.
• X11 runs 'mostly' as root. I don't think I have to explain why a billion lines of unmaintained code running with root can be a bad idea. There are ways to run X11 as non-root only, but this is just another bandaid people invented. It still is way better than running it as is tho.
• Not to mention a lot of the security problems with X11 are not pointed out as vulnurabilities because they are features.

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.

I would appreciate if there are other alternatives to get Wayland support. Ones that do not involve GNOME or KDE.

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.

[adrelanos]

More way towards Wayland to consider:

• Wayfire: https://forums.whonix.org/t/wayfire-wayland-support/18177
• LXQt: https://forums.whonix.org/t/lxqt-wayland-support/18178

---

What's the problem with LXQt in Debian?

[adrelanos]

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.

• X11 security- It's worse than it looks
• X Server Security Disaster: "It's Worse Than It Looks"

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: Actually a survey is in DRAFT status at time of writing. https://www.whonix.org/wiki/Community_survey

(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) https://xkCD.com/1200/

[monsieuremre]

What's the problem with LXQt in Debian?

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 are using a rolling distro for ease, or we package upstream lxqt ourselves.
• (Testing) We test for a very little time to see how stuff work around.
• If things are more or less passable, meaning that most basic things work, we go full time all in cold turkey everything wayland, dropping x11 support.
• We observe some more problems report them upstream, collaborate with upstream whenever possible, submit logs and stuff, try fastening up the progress by getting more involved whenever we are able to.

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.

[adrelanos]

What's the problem with LXQt in Debian?

The problem is that is one thousand years behind upstream.

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.

• We are using a rolling distro for ease, or we package upstream lxqt ourselves.

If not changing the base, we should (if this is reasonably possible of course) package stuff ourselves.

I don't think I can do this.

Kicksecure packages Hardened Malloc from the tarball.

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.

[monsieuremre]

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 one click -> code execution -> mac policy does not allow the execution -> so actually no exection.

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 gnome-core packages here, and what it pulls. Everything here is a legit desktop component. The list is not as long as the kde one. There are around 40-50 packages, and non of them are libraries that are hard to figure out like the case in kde. They are all packages with names that are self-explainatory. We can pick and choose from this list on demand, and leave some of them out of the default kicksecure installation. For example, since we already install vlc, we would not pull totem from gnome-core. I am in support of exploring this option.

[adrelanos]

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:

• No GNOME 1 click libque vulnerability.

B) Xfce with apparmor.d:

• No GNOME 1 click libque vulnerability.
• Even better for defense in depth.

C) GNOME without apparmor.d:

• 1 click libque RCE. Malicious code already running locally.

D) GNOME with apparmor.d:

• 1 click libque RCE. Malicious code already running locally.
• Contained thanks to apparmor.d.
• Hope for the best there's not another vulnerability, an exploit chain in AppAmor / Linux / Wayland and anything else which tracker-miners is allowed by apparmor.de to interact with.
• Suppose apparmor.d can contain it, tracker-miners can still do everything that tracker-miner is allowed to do by apparmor.d. For example, if the tracker-miners AppAmor profile allows networking, then tracker-miners's full database could have been uploaded to the attacker.

In conclusion, cases A) and B) are still preferable over C) and D). Therefore there's no real alternative to attack surface reduction.

[monsieuremre]

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:

• One click arbitrary code execution vulnurability.
• Also Xorg, which on its own has vulnurabilities as a feature.

Xfce with apparmor.d:

• Vulnurability again.
• Confined with apparmor.d
• Due to using Xorg, the likelyhood of excaping any sandboxing mechanism is infinetely easier.
• This applies to pulseaudio too.
• Also, actually not confined with apparmor.d yet, because it is still not supported in the project yet.

Gnome without apparmor.d:

• Vulnurability

Gnome with apparmor.d:

• Protection against most such vulnurabilities

[adrelanos]

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.

exo-open is a local command-line utility. I think what was vulnerable was if locally executing something such as exo-open https://www.example.com/example.desktop. It's a bit like curl attacker.domain | bash. While bad, that's only a LCE (local code execution) issue and not an RCE. No source I found claims that a simple click on a website resulted in remote code execution.

After writing this I also consulted ChatGPT which explains how this vulnerability could be abused better than I could: https://chat.openai.com/share/577616e9-da48-40c4-826a-927028ce9196

And then used ChatGPT to compare the two vulnerabilities which makes my point and saves me a lot of typing: (Sufficient to scroll down and read the comparison table.) https://chat.openai.com/share/18d8c053-5ba6-44e8-a37a-ea16ecf9657c

---

GNOME and KDE also come with additional bad surprises, not important, attack surface increasing and privacy intrusive features such as GeoClue. Privacy issues: https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/177

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: https://www.kicksecure.com/wiki/Dev/GNOME

---

Due to these unresolved issues, porting to GNOME seems less likely. The most likely approaches towards Wayland currently that I can see currently:

• https://forums.whonix.org/t/wayfire-wayland-support/18177
• https://forums.whonix.org/t/lxqt-wayland-support/18178

[monsieuremre]

After writing this I also consulted ChatGPT which explains how this vulnerability could be abused better than I could:

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.

[adrelanos]

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.

[monsieuremre]

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.

[raja-grewal]

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.

[monsieuremre]

The key question is then of timing, when do we switch?

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 the probably thousands of developers that have worked with X11 over the centuries.

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.

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.

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.

As a side note, I also think that the relatively small amount of dependencies Xfce has is major plus.

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.

[adrelanos]

• No further discussion needed.
• No more advocacy for Wayland needed. I am abundantly convinced that this is a must do.

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).

Next needed:

• instructions:
  • how to install a minimal LXQt with Wayland on Debian (bookworm or trixie) on top of Kicksecure CLI
  • (includes a review of the various package dependencies)
• code:
  • https://github.com/Kicksecure/kicksecure-meta-packages
  • https://github.com/Kicksecure/desktop-config-dist
  • (https://github.com/Whonix/anon-meta-packages)

[monsieuremre]

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.

[monsieuremre]

https://twitter.com/lxqt_project/status/1766417095519047757

It seems the desktop component of lxqt is now wayland ready.

[raja-grewal]

Good news, LXQt 2.0.0 has been released and should have "full Wayland support".

https://github.com/lxqt/lxqt/releases/tag/2.0.0

[adrelanos]

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.

Any update?

[EclipseBazooka]

@monsieuremre

Linux Mint just came out with their new release, first time with wayland support on cinnamon. It is pretty solid I have to say.

Have you tried Kicksecure morphing (LMDE Linux Mint Debian Edition?) I wonder if it would work?\ In the past I tried swdate on Mint before and it worked but the icon didn't show up.

Personaly think Cinnamon has a nicer look then XFCE and I believe it now has experimental Wayland support.