6 ms·

I'd proceed with caution. Apparently it doesn't support Wayland, so when you run it under Wayland it offers you a "Fix it!" button that, when clicked, runs sed

I'd proceed with caution. Apparently it doesn't support Wayland, so when you run it under Wayland it offers you a "Fix it!" button that, when clicked, runs sed on some gdm system config files to revert it to X11 (nevermind that gdm is far from the only way to use Wayland): https://github.com/rustdesk/rustdesk/blob/1.1.9/src/platform/linux.rs#L411-L422 https://github.com/rustdesk/rustdesk/blob/1.1.9/src/platform.... If this is the kind of thing that's considered acceptable by the developer, I'd rather keep their products far away from my machines. A quick glance at the code also reveals an almost complete lack of comments and copious use of unexplained `unsafe`.

mgrandl 4y ago
What the actual fuck…
FieryTransition 4y ago
Thanks for the warning, that is brutal!
jeroenhd 4y ago
I don't think the application can work on Wayland because it can't inject commands. Screen sharing is a possibility, but that's it: injecting key strokes or mouse input into applications can only be done by even worse hacks. That said, the "let's disable Wayland to fix it" approach is very... pragmatic, to say the least. This tool was clearly written by someone with a "make it work for the general public" mindset. And, to be honest, I'm not 100% opposed to this approach, although there should definitely be a giant warning system configuration is changed. When a piece of software says "You are using Wayland and this software requires X11, please change your desktop session type" then you're not helping most people. A simple button to fix the problem can be a lot better than an error message with a link to a complicated step-by-step guide. As is often the case, this client seems to have been made for people running Ubuntu/Fedora, and a relatively recent version at that. The copious amount of unsafe seems to revolve around operating system APIs being called. Interacting with X11 requires tons of unsafe operations, you can't really work around that. The best you can do is make your own wrappers to hide the fact you're calling unsafe code behind the scenes, but I can't see too much unnecessary unsafe code in there to be honest.
- phh 4y ago
  > injecting key strokes or mouse input into applications can only be done by even worse hacks. Hum I don't understand this, I've been injecting key strokes for a decade on any Linux-running system using uinput (which creates a new virtual /dev/input). Is this somehow broken by wayland? (I haven't ever really used wayland, nor do i understand how it works)
  - FreeFull 4y ago
    AFAIK uinput does work just fine with Wayland. I've used sc-controller under Wayland before without any issues, and I believe it makes use of uinput
    - Fnoord 4y ago
      I use Wayland + Sway plus ydotool(d) on a dailty basis (e.g. with libinput-gestures), as well as kbct to rebind keys (main purpose caps to esc and some ctrl/alt/meta/fn rebinds). Both use uinput. Things I could do with xdotool I can also do with ydotool.
      - wawawawaz 4y ago
        I found this comment looking for exactly this. Can you share any advice / config / dotfiles?
- merdzov 4y ago
  It is absolutely possible though, see https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.RemoteDesktop https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free... (And it really should use this on X11 too, and have the current X11 way as a fallback to insane systems that don't have portals in 2022)
  - throwdbaaway 4y ago
    https://knowledgebase.nomachine.com/AR02P00969 https://knowledgebase.nomachine.com/AR02P00969 - and NoMachine seems to have decent support for Wayland.
karlmdavis 4y ago
Underexplained, permanent system config changes? That just about counts as malware, in my book. (Since I use sway on Ubuntu, rather than gdm, I’d argue it’s a capital offense, but YMMV.)
- Erlangen 4y ago
  I am not a user of rustdesk. But from its source code[1], I think does have some warnings about the change. It says, > "Warning" > "Current Wayland display server is not supported" > `Fix it` => a button triggers system gdm config change > A 'Help' link to github, showing how to change the config manaully. I wouldn't count it as malware. But I don't think it's OK to change the system configuration by pressing a button of a remote desktop software. It should simply provide a link to user instead. [1] https://github.com/rustdesk/rustdesk/blob/45375517b960add9010667dcce867d1351f55a6e/src/ui/index.tis https://github.com/rustdesk/rustdesk/blob/45375517b960add901...
  - nyberg 4y ago
    It doesn't adequately explain what it does before having you ruing your configuration nor should it really be part of this application. An informative message explaining that the application doesn't work on wayland, why, and a link to a page with solutions would have been much better and not placed the user at risk.
pizza234 4y ago
Yikes. This is not well-written Rust; code like the below actually defeats the purpose of using Rust, and without any specific reason for doing so. I personally discourage people from using this software. static mut KEYBOARD_HOOKED: bool = false; fn start_keyboard_hook(&self) { if unsafe { KEYBOARD_HOOKED } { return; } } The build even requires an assembler (NASM), which is odd, in this context.
- mwcampbell 4y ago
  I disagree. Not all Rust code needs to be maximally generalized and reusable. If this were library code, I might feel differently. But here we're looking at code for installing a global, system-wide keyboard hook. Using a global variable is a direct, pragmatic, no-nonsense way of doing it. Edit: Further, there's no such thing as "the purpose of using Rust". Different users can use the same tool for different purposes, and Rust is no different.
  - pizza234 4y ago
    That's fair, but I seriously consider the danger of a slippery slope. To keep in mind, on a pragmatic level, that this type of global can be trivially implemented, at a minimum, via atomics, so the cost to avoid the unsafe is near-zero. Atomics are not supported by all the platforms, but based on my understanding of their targets (x86-64), they're supported.
  - FreeFull 4y ago
    At the very least, I would have used an AtomicBool rather than a static mut. See https://github.com/rust-lang/rust/issues/53639 https://github.com/rust-lang/rust/issues/53639 . As a bonus, AtomicBool doesn't require any unsafe code.
- staticassertion 4y ago
  It's not that big of a deal tbh and I'm actually not sure there's even a practical safety issue, though there could be bugs if the compiler makes some optimizations based on that (unlikely imo). AFAIK on any typical platform there's no way you'd have "tearing" for a single byte ie: this will never store an invalid boolean representation.
causality0 4y ago
The poor English, use of stock images, and absolutely zero information about the individual people behind the project are also red flags.
R0b0t1 4y ago
There's no way to get it to work with Wayland, by design.

mgrandl 4y ago

What the actual fuck…

FieryTransition 4y ago

Thanks for the warning, that is brutal!

jeroenhd 4y ago

I don't think the application can work on Wayland because it can't inject commands. Screen sharing is a possibility, but that's it: injecting key strokes or mouse input into applications can only be done by even worse hacks. That said, the "let's disable Wayland to fix it" approach is very... pragmatic, to say the least. This tool was clearly written by someone with a "make it work for the general public" mindset. And, to be honest, I'm not 100% opposed to this approach, although there should definitely be a giant warning system configuration is changed. When a piece of software says "You are using Wayland and this software requires X11, please change your desktop session type" then you're not helping most people. A simple button to fix the problem can be a lot better than an error message with a link to a complicated step-by-step guide. As is often the case, this client seems to have been made for people running Ubuntu/Fedora, and a relatively recent version at that. The copious amount of unsafe seems to revolve around operating system APIs being called. Interacting with X11 requires tons of unsafe operations, you can't really work around that. The best you can do is make your own wrappers to hide the fact you're calling unsafe code behind the scenes, but I can't see too much unnecessary unsafe code in there to be honest.

phh 4y ago
> injecting key strokes or mouse input into applications can only be done by even worse hacks. Hum I don't understand this, I've been injecting key strokes for a decade on any Linux-running system using uinput (which creates a new virtual /dev/input). Is this somehow broken by wayland? (I haven't ever really used wayland, nor do i understand how it works)
- FreeFull 4y ago
  AFAIK uinput does work just fine with Wayland. I've used sc-controller under Wayland before without any issues, and I believe it makes use of uinput
  - Fnoord 4y ago
    I use Wayland + Sway plus ydotool(d) on a dailty basis (e.g. with libinput-gestures), as well as kbct to rebind keys (main purpose caps to esc and some ctrl/alt/meta/fn rebinds). Both use uinput. Things I could do with xdotool I can also do with ydotool.
    - wawawawaz 4y ago
      I found this comment looking for exactly this. Can you share any advice / config / dotfiles?
merdzov 4y ago
It is absolutely possible though, see https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.RemoteDesktop https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free... (And it really should use this on X11 too, and have the current X11 way as a fallback to insane systems that don't have portals in 2022)
- throwdbaaway 4y ago
  https://knowledgebase.nomachine.com/AR02P00969 https://knowledgebase.nomachine.com/AR02P00969 - and NoMachine seems to have decent support for Wayland.

karlmdavis 4y ago

Underexplained, permanent system config changes? That just about counts as malware, in my book. (Since I use sway on Ubuntu, rather than gdm, I’d argue it’s a capital offense, but YMMV.)

Erlangen 4y ago
I am not a user of rustdesk. But from its source code[1], I think does have some warnings about the change. It says, > "Warning" > "Current Wayland display server is not supported" > `Fix it` => a button triggers system gdm config change > A 'Help' link to github, showing how to change the config manaully. I wouldn't count it as malware. But I don't think it's OK to change the system configuration by pressing a button of a remote desktop software. It should simply provide a link to user instead. [1] https://github.com/rustdesk/rustdesk/blob/45375517b960add9010667dcce867d1351f55a6e/src/ui/index.tis https://github.com/rustdesk/rustdesk/blob/45375517b960add901...
- nyberg 4y ago
  It doesn't adequately explain what it does before having you ruing your configuration nor should it really be part of this application. An informative message explaining that the application doesn't work on wayland, why, and a link to a page with solutions would have been much better and not placed the user at risk.

pizza234 4y ago

Yikes. This is not well-written Rust; code like the below actually defeats the purpose of using Rust, and without any specific reason for doing so. I personally discourage people from using this software. static mut KEYBOARD_HOOKED: bool = false; fn start_keyboard_hook(&self) { if unsafe { KEYBOARD_HOOKED } { return; } } The build even requires an assembler (NASM), which is odd, in this context.

mwcampbell 4y ago
I disagree. Not all Rust code needs to be maximally generalized and reusable. If this were library code, I might feel differently. But here we're looking at code for installing a global, system-wide keyboard hook. Using a global variable is a direct, pragmatic, no-nonsense way of doing it. Edit: Further, there's no such thing as "the purpose of using Rust". Different users can use the same tool for different purposes, and Rust is no different.
- pizza234 4y ago
  That's fair, but I seriously consider the danger of a slippery slope. To keep in mind, on a pragmatic level, that this type of global can be trivially implemented, at a minimum, via atomics, so the cost to avoid the unsafe is near-zero. Atomics are not supported by all the platforms, but based on my understanding of their targets (x86-64), they're supported.
- FreeFull 4y ago
  At the very least, I would have used an AtomicBool rather than a static mut. See https://github.com/rust-lang/rust/issues/53639 https://github.com/rust-lang/rust/issues/53639 . As a bonus, AtomicBool doesn't require any unsafe code.
staticassertion 4y ago
It's not that big of a deal tbh and I'm actually not sure there's even a practical safety issue, though there could be bugs if the compiler makes some optimizations based on that (unlikely imo). AFAIK on any typical platform there's no way you'd have "tearing" for a single byte ie: this will never store an invalid boolean representation.

causality0 4y ago

The poor English, use of stock images, and absolutely zero information about the individual people behind the project are also red flags.

R0b0t1 4y ago

There's no way to get it to work with Wayland, by design.