4 ms·

> I know there are theoretical issues with the X security mode, but this replacement is a classic case of “security” producing something that’s basically useles

> I know there are theoretical issues with the X security mode, but this replacement is a classic case of “security” producing something that’s basically useless for what people use the software for. I keep reminding people that one of the most known models for security is "confidentiality, integrity and availability". If it isn't available your security is still somehow broken however well one scores on confidentiality.

canofbars 6y ago
Wayland security is not broken. Its just a single piece in a much longer term goal that spans many components. Linux was not designed for the current era where users run untrusted and borderline malicious programs regularly. While wayland may secure the desktop, there are 20 other places where programs can scoop up your data. It looks useless now but without every part being fixed individually it will be impossible to create a secure linux desktop that runs proprietary applications.
- smichel17 6y ago
  Tbh I'd much rather fight this on the front of "let's not need to run untrusted and borderline malicious programs regularly" than breaking the free world in order to make it possible.
  - canofbars 6y ago
    That fight was long long lost. We will never ever make things like video games open source. But we can sandbox them. Even open source tools could do with being sandboxed. I don't see why this is an issue. The user still has full power to do anything and its is only programs which are restricted. Under the new model, instead of a tool just grabbing your screen, it must now make a request to the OS which will show a popup asking if you want to allow access and if you accept the program can continue as it would have before.
    - fiddlerwoaroof 6y ago
      The issue I have with wayland is that it just continues to fragment the Linux desktop ecosystem, and it moved things to the toolkit that just don’t make sense there: I don’t want my window decorations to depend on whether the app is built with Qt or Gtk. I don’t want projects like McClim ( https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/ ) to depend on C code to communicate with the windowing system, etc.
      - cycloptic 6y ago
        So for window decorations, it's up to the app developer if they want to implement special behavior for client side decorations or not. If they do, there's nothing your toolkit or window manager can really do about it, you have to show the client's window decorations or you will lose functionality. Wayland has little to do with that. About depending on C code, Wayland is pretty much the same as X11 there. If you don't want to use libwayland, you can write your own implementation of the wire protocol.
        fiddlerwoaroof 6y ago
        This isn't true: https://news.ycombinator.com/item?id=19783044 https://news.ycombinator.com/item?id=19783044
        cycloptic 6y ago
        You didn't say hardware acceleration initially. If you need hardware acceleration you will have to link against Mesa/OpenGL for direct rendering anyway, which is a giant C library, so yeah the dependency on external C is somewhat unavoidable there under any windowing system. If you consider linking against libGL and libEGL to be okay but not libwayland then there actually is a workaround: forget the EGL wayland platform and have your custom wayland implementation use the EGL GBM platform. There's some extra code you have to write here but unless something changed that I missed, the same problem exists with Xlib if you try to use the EGL X11 platform, or if you want to use direct rendering in GLX. (Mesa's libEGL/libGLX links against libX11 and expects to get a structure with the C ABI. Keep in mind if you are using GLX calls in that CLX library, you are probably not getting direct rendering, you would have to do a similar thing and reimplement the DRI2/DRI3 path from Mesa in your toolkit or application)

canofbars 6y ago

Wayland security is not broken. Its just a single piece in a much longer term goal that spans many components. Linux was not designed for the current era where users run untrusted and borderline malicious programs regularly. While wayland may secure the desktop, there are 20 other places where programs can scoop up your data. It looks useless now but without every part being fixed individually it will be impossible to create a secure linux desktop that runs proprietary applications.

smichel17 6y ago
Tbh I'd much rather fight this on the front of "let's not need to run untrusted and borderline malicious programs regularly" than breaking the free world in order to make it possible.
- canofbars 6y ago
  That fight was long long lost. We will never ever make things like video games open source. But we can sandbox them. Even open source tools could do with being sandboxed. I don't see why this is an issue. The user still has full power to do anything and its is only programs which are restricted. Under the new model, instead of a tool just grabbing your screen, it must now make a request to the OS which will show a popup asking if you want to allow access and if you accept the program can continue as it would have before.
  - fiddlerwoaroof 6y ago
    The issue I have with wayland is that it just continues to fragment the Linux desktop ecosystem, and it moved things to the toolkit that just don’t make sense there: I don’t want my window decorations to depend on whether the app is built with Qt or Gtk. I don’t want projects like McClim ( https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/ ) to depend on C code to communicate with the windowing system, etc.
    - cycloptic 6y ago
      So for window decorations, it's up to the app developer if they want to implement special behavior for client side decorations or not. If they do, there's nothing your toolkit or window manager can really do about it, you have to show the client's window decorations or you will lose functionality. Wayland has little to do with that. About depending on C code, Wayland is pretty much the same as X11 there. If you don't want to use libwayland, you can write your own implementation of the wire protocol.
      - fiddlerwoaroof 6y ago
        This isn't true: https://news.ycombinator.com/item?id=19783044 https://news.ycombinator.com/item?id=19783044
        cycloptic 6y ago
        You didn't say hardware acceleration initially. If you need hardware acceleration you will have to link against Mesa/OpenGL for direct rendering anyway, which is a giant C library, so yeah the dependency on external C is somewhat unavoidable there under any windowing system. If you consider linking against libGL and libEGL to be okay but not libwayland then there actually is a workaround: forget the EGL wayland platform and have your custom wayland implementation use the EGL GBM platform. There's some extra code you have to write here but unless something changed that I missed, the same problem exists with Xlib if you try to use the EGL X11 platform, or if you want to use direct rendering in GLX. (Mesa's libEGL/libGLX links against libX11 and expects to get a structure with the C ABI. Keep in mind if you are using GLX calls in that CLX library, you are probably not getting direct rendering, you would have to do a similar thing and reimplement the DRI2/DRI3 path from Mesa in your toolkit or application)