Good idea, worth checking out security concerns there.
I believe we replaced this with loupe actually. lximage-qt would have fit better with the theme and would have even worked, but loupe uses an image loading library known as Glycin which is written in Rust and sandboxed, which is why we went with it.
What is X11-y about featherpad? It works with Wayland just fine, even when Xwayland is off.
Same question as for Featherpad, I guess I don’t know if this one connects to Wayland but I would assume it can. Does the window vanish if you pkill Xwayland (or pkill xwayland, don’t remember which one)?
Same question as for VLC.
Same question as for VLC.
Same question as for Featherpad, this one should also just work with Wayland as it’s a Qt app.
Depends on libx11-6, if purely wayland this will be ignored/functional? if so, then i can list all default lxqt tools which comes with debian and developed/chosen by the lxqt upstream as well.
(the rest have the same thing, depends on 1 or so x11 lib)
Didnt test just chosen the tools which doesnt contain any x11 thing within it.
Yeah hope it can be avoided but not sure thats possible
I would be very desirable to avoid pulling in “unnecessary”, duplicatory
gnome dependencies. People might be OK with lxqt, but pulling in lots
of deps from another desktop env (gnome) is just annoying, increasing
the sense that “whionix is bloated”.
Package names alone will result in a suspected use of X11 but not in a confirmed case of X11.
It could either be just the name. The name x11 will remain for historical reasons in some places for a while. For example, localectl list-x11-keymap-variants is still a thing. That does not mean that an X11 display server is being used.
Or it could be compatible with both, X11 and Wayland.
Good point, do you have an easy method to turn off xwayland entirely from lxqt-labwc on ks/whonix? or i should download labwc and build it from upstream without xwayland (cant remove xwayland without removing labwc when installed from debian)?
Since the removal of xwayland not possible and its not clear what will work and what not work on purely wayland, then i see it better to stick with the upstream/debian Qt default packages:
2. Start xeyes, an application that is “guaranteed” (at least during Debian trixie) to be using X11.
xeyes
3.Make sure xeyes is outside your virtual terminal because xeyes does not have a task bar entry and might be behind the virtual terminal emulator, thereby invisible. In other words, have a virtual terminal window next to xeyes.
4. Check that Xwayland is running. (Optional.)
ps aux | grep -i xwayland
5. Kill xwayland. Open another virtual terminal tab and run.
pkill -i --signal sigkill xwayland
6. Done.
Expected result: xeyes (and all other applications using XWayland) windows will vanish. The eyes process will also be terminated.
All these GNOME choices for software… Aren’t they going to make the
whonix-18 look overly GNOME-ish, even though it is supposed to use LXQt?
Like, the visual character of the tools going to contain GNOME modals.
Also, do these GNOME software bring with them GNOME dependencies
installed from debian repos (and thus contribute to “bloatiness”)?
Technically yes, however in practice GNOME apps seem to require a lot less dependencies than, say, KDE apps, so it’s not a very large impact. A large portion of the software available for Linux also relies on libraries like GTK and libadwaita, so avoiding GNOME dependencies is virtually impossible and would severely limit what Kicksecure could do if we pursued that.
Personally, I’d vote for removing the PDF viewer without replacement, because xpdf, qpdfview, and Papers all use Poppler or code similar to Poppler under the hood (Poppler is a library fork of xpdf). Poppler is highly sensitive to security issues, has fairly frequent security updates (indicating frequent security issues), and modern web browsers like Tor Browser can handle PDF rendering in a sandboxed context. I.e., Tor Browser is a suitable PDF viewing application and is likely much, much safer than most standalone PDF renderers for Linux. Tor Browser best practices - Security - Tor Browser — Tor effectively says that opening untrusted PDF files in Tor Browser should be safe:
You should be very careful when downloading documents via Tor (especially DOC and PDF files, unless you use the PDF viewer that’s built into Tor Browser)
Screengrab would have been preferable, but it lacks the ability to capture a Wayland desktop screenshot in Trixie (i.e. it’s entirely useless at the moment). We should switch from Flameshot to Screengrab in Forky most likely.
Doesnt run in KS.. (for me thats great to see x11 thing which doesnt work, but might be better if possible to show a message that this is x11 app which cant be running or so).
Other stuff mentioned in this thread looks good, so we go with functional with pure wayland + better used coding for security (but somewhat neglect bloating and DEs components/apps mix up).