Run the GNOME session on Wayland instead of X.Org, and adjust whatever is needed, such as:
- We run quite a few of GUI apps under gksudo/pkexec/sudo, such as the
Unsafe Browser. This can be worked
for apps that run via XWayland (i.e. not Wayland-native apps) with
xhost +si:localuser:root, which might be acceptable as a temporary transition measure, as long as there’s a clear plan to fix that at some point (since it defeats some of the benefits of switching to Wayland in the first place, such as security improvement, a11y / IBus / on-screen keyboard support in all graphical apps)
- Consider dropping the 89cc641f39a5414e763112f698739bb2351da7d8 hack: there are rumors that GDM’s session does not linger after login on Wayland.
Last time we discussed our strategy, we decided this:
- Focus on real blockers
- Workarounds are OK, like XWayland
- OTOH we currently have several bugs that would remain if we use XWayland, like lack of accessibility support, on-screen-keyboard support. So if we have to do significant work we should bundle in making it Wayland native & fixing these issues as well.
- Tor Launcher MUST run as a native Wayland app (contractual obligation to Sponsor8)
- Debian bugs tagged wayland
Blockers that can be implemented incrementally
i.e. without waiting for the "switch to Wayland" flag day
#8573 (the only X.Org specific bits remaining in our test suite are about Pidgin)
#18020: probably ok with XWayland, although we'll get all the bugs/security issues we have in Xorg (no a11y etc, but in particular #15635)
- #14718: XWayland is OK for now, until we switch to a non-NIH upgrader; splitting out a backend would allow integrating the UI into a potential Tails Settings application.
config/chroot_local-includes/usr/lib/systemd/user/org.gnome.Shell@x11.service.d/: probably it will have a different name on Wayland
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information