01:27 <orowith2os[m]> Hm, is there some special thing we need to do to get keybinds working with MangoHud on Wayland?

01:28 <orowith2os[m]> https://github.com/flightlessmango/MangoHud/blob/3922da8a3990e6d6dd6d4b6ef13a433217367ae2/src/keybinds.h

01:28 <orowith2os[m]> mangohud currently hooks into libx11 and the windows api to get the currently pressed keys

01:29 <orowith2os[m]> this probably can't be done as cleanly in Wayland, right?

07:38 <MrCooper> orowith2os[m]: offhand seems like it should be possible, I have to defer to others for how exactly though

07:51 <jadahl> MrCooper: sounds non-trivial. it looks like it opens its own X11 connection, and queries a set of key state, a.k.a. backdoor keylogging. in Wayland it'd need to get access to the clients wl_pointer some how

07:52 <MrCooper> can't create its own wl_pointer?

07:52 <jadahl> maybe if it wrapped some libwayland API it could do it

07:52 <jadahl> still need the wl_display

07:54 <MrCooper> how does it get the Display with X?

07:56 <MrCooper> hmm, or maybe it can use its own

07:59 <YaLTeR[m]> MrCooper: wouldn't that mess with the client's Wayland state

08:00 <MrCooper> AFAIK that can be avoided with Wayland, in contrast to X

08:02 <jadahl> YaLTeR[m]: it'd just eaves drop, not alter

18:13 <orowith2os[m]> MrCooper jadahl fwiw someone brought up the Wayland keylogger project, so definitely seems possible. I'll bug y'all more if there are any questions :)

18:15 <emersion> the wayland keylogger project is a bit of a joke

18:15 <emersion> it's just a suid executable which reads uinput

18:16 <emersion> and then the peanut gallery shouts "wayland insecure"

18:16 <psykose> did you know as root on linux you can do anything?

18:16 <psykose> unheard of

18:17 <emersion> "but wayland is supposed to prevent that"

18:19 <kennylevinsen> orowith2os: a keylogger approach would be adversarial in nature, so don't do that :)

18:20 <kennylevinsen> The hotkey protocol/portal might be relevant, and a Wayland proxy could monitor a specific application (wlhax-style) if that is the goal... But what are the key bindings for in the first place?

18:22 <orowith2os[m]> emersion: oh, I thought it used LD_PRELOAD to grab inputs from a client?

18:23 <emersion> oh, i might mix it up with another attempt

18:23 <orowith2os[m]> kennylevinsen: this is for Mangohud, so anything involving user interaction is a no-no. If either that protocol or portal can get by that, it'll be fine

18:24 <orowith2os[m]> emersion: here's the one I might be thinking of: https://github.com/Aishou/wayland-keylogger

18:29 <kennylevinsen> Protocol/portal would allow you to register keybindings, no sniffing - as is the Wayland way

18:30 <kennylevinsen> I have no idea what mangohud is or why that would rule out user interaction

18:32 <kennylevinsen> Such things tend to just boil down to "it differs from what we did before"...

18:32 <emersion> i wouldn't be concerned about magohud doing hacks, it's already doing some to insert its own rendering so shrug

18:33 <orowith2os[m]> mangohud is loaded into an application and gives you an overlay containing the performance metrics and stuff

18:33 <orowith2os[m]> a quick google search will get you tons of hits; you've probably already seen it

18:34 <orowith2os[m]> it's expected that when you load mangohud into an application, that's it - everything will read your mangohud config file and Just Work™

18:34 <orowith2os[m]> a portal or protocol that requires explicit user permission would make that instead two or three steps, and that's not ideal

18:35 <kennylevinsen> Yeah that's what I mean, no real reason there couldn't be interaction (e.g. ports prompt) other than "there isn't any right now"

18:36 <kennylevinsen> But if it's already an injection hack, and only wraps 1 application, a Wayland proxy or LD_PRELOAD could work

18:37 <kennylevinsen> s/ports/portal/

18:55 <orowith2os[m]> kennylevinsen: also, we don't need the shortcuts to be global :P

18:56 <orowith2os[m]> anyways someone's looking at it more now

18:59 <Arnavion> If you only need the keybinds to work when the window is focused, then you could "just" intercept the wayland client connection so that you see the incoming keyboard messages first

19:00 <orowith2os[m]> is there a PoC for that?

19:07 <jadahl> orowith2os[m]: you can make one. create a .so file that has wl_display_connect() exported. in there, dlopen libwayland-client.so and find the correct wl_display_connect address. when you get called, call the "real" function, but store away a proxy wrapper of the return value. get your own registry, find the seat, get a wl_keyboard and start listening to events.

19:09 <ids1024> `wayland-keylogger` is a good demonstration that Wayland in itself doesn't provide security against malicious apps without additional sandboxing. It has nothing specifically to do with Wayland though, other than the particular symbols it overrides with LD_PRELOAD.

19:09 <Arnavion> A less hacky way is to run as a separate process that execs the target application with a $WAYLAND_DISPLAY pointing to a socket managed by your mangohud process

19:10 <orowith2os[m]> ids1024: wayland-keylogger is a good demonstration that we need to push for Flatpak and MACs more :P

19:10 <orowith2os[m]> jadahl: thanks, will look into it - and it fits in with the mangohud architecture to have it be an LD_PRELOAD bit

19:12 <Arnavion> Note that the LD_PRELOAD'ing to hook libwayland-client functions only works for processes that use libwayland-client

19:12 <Arnavion> Worst case you'll have to hook connect()

19:19 <jadahl> Arnavion: it'll likely be a libwayland-client client since it's meant for vulkan/gl overlays

19:20 <orowith2os[m]> it's also possible that some other, non-libwayland-client client, exists that could use this, but it's complicated and unlikely to happen

19:20 <orowith2os[m]> (and I'm not even sure if it would work for those cases)

20:57 <orowith2os[m]> looks like it was already attempted, and if I'm understanding it correctly it does.... something.... with WSI: https://github.com/flightlessmango/MangoHud/commit/26c8d1dbdda16ae3af53c3aa7a71eaeb3ffd4acd