5 ms·

I am the maintainer of the most influential library in the Wayland ecosystem, forming the foundation of a strong majority of Wayland compositors, and the author

I am the maintainer of the most influential library in the Wayland ecosystem, forming the foundation of a strong majority of Wayland compositors, and the author of a popular Wayland compositor on top of this still. Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. Here is my appeal to the author, with some edits for the sake of general audiences: >I'd like to ask you to update this with a retraction at the top. I'm not sure if you recall when we spoke about this on IRC a few months ago, but each of these points is entirely false, and the article is a dishonest smear on Wayland (though I assume you only had the best of intentions). To recap: >1 - recording events from libinput only works if you're root, and if you're root, you can do whatever you want. This is hardly a valid criticism of Wayland. LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. None of this is a mark against Wayland - it's only one part of a secure system, and the other parts are mandatory. >2 - Wayland is a protocol, not its implementation. And many implementations are widely supported by older hardware. wlroots, which is the dominant Wayland ecosystem with over 75% of all compositors using it for their rendering, requires only GLESv2, which is the most broadly supported OpenGL standard. >3 - The headline doesn't match the body, but both are wrong. The design of Wayland and its implementations is indeed much simpler than X11/xorg-server. As for the use-cases brought up in the body of this point, the caracatures of Wayland developers are rude and incorrect. For network transparency, it wouldn't be difficult but no one who cares has stepped up to do the work. Multiple clipboards are now supported. Many of the pieces of remote desktop are in place, and again someone who cares needs to step up to implement the rest and tie it together. We are ready and waiting to support anyone who wants to step up to complete this work. >4 - A bug in xorg-server will similarly bring down your X session. Driver bugs affect both. Bugs are addressed when they're found, what more do you want from us? Regardless, restart protocols are in the research phase and your comments about the security holes implicated are blatant speculation. >Support whatever you wish in your distro, but please don't publish dishonest articles.

CyberShadow 8y ago
> Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. That doesn't sound reasonable. > LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? > >4 - A bug in xorg-server will similarly bring down your X session. A Xorg server needs to implement: - the display server A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions. I'm not really sure what's XWayland's story security-wise, but from my limited understanding, it is a component that is not going away soon, and allows bypassing some limitations of Wayland's API in order to accommodate X11 clients.
- ddevault 8y ago
  >This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? It's not the Wayland compositor's responsibility to provide an entire security solution, just like it's not the deadbolt manufacturer's responsibility to install an alarm system and security cameras. This isn't a criticism of Wayland, at best it's a criticism of your Linux distro. Flatpak does answer this question, but fwiw in the Sway camp we're still looking into lighter-weight solutions. >A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions. This is only partially true. wlroots implements screenshots the same way that xorg-server does: by providing an API for exporting pixels to clients. The actual screenshot tool is a standalone program which can crash without affecting the compositor. This design is virtually identical to X, except easier to secure. The same can be said of many of your other points.

CyberShadow 8y ago

> Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. That doesn't sound reasonable. > LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? > >4 - A bug in xorg-server will similarly bring down your X session. A Xorg server needs to implement: - the display server A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions. I'm not really sure what's XWayland's story security-wise, but from my limited understanding, it is a component that is not going away soon, and allows bypassing some limitations of Wayland's API in order to accommodate X11 clients.

ddevault 8y ago
>This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? It's not the Wayland compositor's responsibility to provide an entire security solution, just like it's not the deadbolt manufacturer's responsibility to install an alarm system and security cameras. This isn't a criticism of Wayland, at best it's a criticism of your Linux distro. Flatpak does answer this question, but fwiw in the Sway camp we're still looking into lighter-weight solutions. >A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions. This is only partially true. wlroots implements screenshots the same way that xorg-server does: by providing an API for exporting pixels to clients. The actual screenshot tool is a standalone program which can crash without affecting the compositor. This design is virtually identical to X, except easier to secure. The same can be said of many of your other points.