X.Org Server & XWayland Updated Due To Another Six Security Vulnerabilities

[ssokolow]

Although I don't know much about the specifics or the lists that are being made, my impression is that X11 defenders are asking for features in a way that defeats security (or doesn't fit Wayland). That's fighting windmills. The time is over and done.

If they want to be constructive, they need to find a way to implement any features they need or want, within the security and architecture concepts of Wayland. They need to become Wayland fans and then find a way for these features. With security.

The reasonable among us are basically saying "You promised a system for allowing specific applications to be launched with access to restricted-access privileged APIs (eg. desktop-agnostic monitor control panels) over a decade ago as part of Wayland's original vision. Now you're trying to push people to Wayland when you still haven't even spec'd that out, let alone implemented it!" (While Arcan already has a solid system for it. IIRC, it involves handing the process a pre-opened socket with elevated privileges attached as part of launching it.)

In short, we're pushing back against an attitude that feels like "It's too much work to figure out a solution for reconciling your needs with Wayland's security model. Therefore, we're declaring your needs invalid."

(Just look at how much of a struggle there's been (still ongoing) to get a way for things like Appimages or single-file PyQt/PyGObject scripts or applications running from ~/src/my_git_checkout to have icons other than the stock Wayland one without first installing themselves into the system... I don't want to go back to the days of Quarterdeck/Symantec Cleansweep.)

[Luke]

<snip>
Yes, Wayland is an ongoing progress and development, but at least some developers work on it while the developers of Cinnamon, MATE just wait for others to make everything for them.
collaoration is key if we want to see Wayland adopted faster and have more of the missing features implemented!

Not exactly: try building MATE from git master with wayland enabled wherever that is specified as an option, and include mate-wayland-session (which depends on wayfire). Fire the session up from SDDM or another wayland-friendly display manager, and you will be pleasantly surprised. First up, you get icons on the desktop and can manage the background by right-clicking on the desktop too. This is on the first monitor (usually leftmost, whatever comes up as monitor 0), multimonitor support is on the todo list for this.

Mate-panel is now one of the most full featured panels available for wayland, only things missing are the show desktop applet (you can do that job with a keyboard shortcut), the workspace switcher applet (all the other ways of switching workspaces work), and per-workspace management of windows in the window list.

Still plenty of papercuts but we are doing what we can to ensure no distro has to dump MATE because they dump x11. We are keeping x11 support around as long as it is available too, we are not going wayland-only unless we get to the point that almost no distro is shipping x11.No matter which way this one jumps, we will be ready.

[Luke]

Cinnamon too is reported to have experimental wayland support either out or under development

[t1r0nama]

LOL!
Imagine still using X in 2024...
I bet this will still not scare Linux Mint fanboys!
As for them "Well, it works!" it's normally the only requirement.

Last time i checked (week ago) steam still does not run on wayland so....

[t1r0nama]

I meant that Linux Mint users often recommend Cinnamon or Linux Mint distro because they just work.
When other mainstream DEs like MATE, XFCE, KDE Plasma, Gnome and window managers just work too.

Gnome does not "just work". Have seen far too many times when it broke after update. It happened on my friends systems and on my coworkers too. I always suggest them to move to XFCE. In my experience it's much more stable then gnome.

[mdedetrich]

Sorry for being pedantic here, but it's NVIDIA that's still crap under Wayland.

NVIDIA has to actively support Wayland, or don't. Since a protocol can't do much to accommodate vendor-specific quirks, and it's working just fine for the other vendors. There's no denying the issues users are facing, but blaming NVIDIA properly identifies on whose shoulders the responsibility lies.

The reason NVidia doesn't support Wayland fully is because the Linux kernel/graphics stack is missing proper explicit sync support, something that other GPU makers (intel/AMD) have also complained about.

So the Linux kernel/graphics stack being built around decades old outdated implicit sync design is where the responsibility lies. Thankfully this is slowly being fixed.

[lowflyer]

To all similar comments like this one:

this is the reason why we need wayland

Don't blindly bet on wayland. Wayland REALLY REALLY needs to get their act together.
Slowly eating up all issues in X.Org one-by-one can bring X.Org to a better standing than wayland.

[varikonniemi]

The problem with a bunch of fragmented Wayland compositors is that no-one will ever comb through them. The codebases are too large and too full of old versions of duplicate code.

Unless a law comes into force that they *all* have to be based on wl_roots?

It's way worse on X. There you have the compositors AND the server that contain bugs. And unless you rewrite the x server, it will always contain proportionally more bugs due to how old and unmaintainable the code is. Same is not true for DE compositors.

[kpedersen]

It's way worse on X. There you have the compositors AND the server that contain bugs. And unless you rewrite the x server, it will always contain proportionally more bugs due to how old and unmaintainable the code is. Same is not true for DE compositors.

The Xorg server is one codebase. As you have seen people are combing through it and they are finding bugs and fixing them as part of ongoing maintenance of Xorg. Since the removal of user-mode graphics drivers, the Xorg server isn't even that large. It is more maintainable than it was 10 years ago.

The window managers however are generally very small (Xorg does most of the heavy lifting) so there is little code to maintain. And the best bit is, if they do crash, they don't take out the entire display system unlike Wayland compositors.

Whereas Wayland compositors are all very large and monolithic. Each one is potentially large to maintain and each one generally has less developers working on them than Xorg.

[varikonniemi]

xserver+client is much worse to maintain than a wayland compositor. It's not only that xserver is old and bad code, but because the design is shit the shittiness leaks into your client implementation making also it stink.

Compare this to for instance cosmic desktop. Modern code that interacts with modern kernel interfaces. From the very first alpha release it will not contain several class of bugs in the wayland compositor, but which will forever plague xserver and all DE:s that use it today. Why? Because it can be written in Rust. To fix this on X side you would need to rewrite xserver in Rust or another language that provides similar guarantees.