01:31 wlb: weston Merge request !1389 closed (replace weston_signal_emit_mutable with wl_signal_emit_mutable)
01:42 wlb: weston Merge request !1391 opened by HeYong (HeYong) replace weston_signal_emit_mutable with wl_signal_emit_mutable https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1391
03:54 DemiMarie: Is wlroots known to use the GPU inefficiently, or are the benchmarks in <https://github.com/CuazroSoftware/Louvre> bad?
04:09 bl4ckb0ne: the link is 404
05:05 i509vcb: swap c and z
05:09 DemiMarie: https://github.com/CuarzoSoftware/Louvre claims to use the CPU and GPU more efficiently than Sway or Weston, and their benchmarks appear to show Sway using the GPU very inefficiently.
05:23 fluix: I'm curious about the FPS claims: is it saying wlroots rendering can drop to half the refresh rate (when there's lots of moving surfaces)?
05:24 fluix: kind of odd that it also only happens between... 2-19ish and 25+ surface
05:30 kchibisov: it's kind of odd that both weston and sway dropped to exactly 30 fps.
05:50 kchibisov: I'd assume it's because renderer can't make it in time, so it waits for next vblank?
05:55 DemiMarie: exactly @_oftc_kchibisov:matrix.org
05:55 DemiMarie: (also which Matrix room are you using?)
05:56 kchibisov: I don't use matrix.
07:30 pstch: hi there
07:31 pstch: what is the preferred protocol now to ensure that input to other clients is inhibited ? there is wlr-input-inhibitor-unstable-v1 (implemented in sway), but it's been deprecated in favor of a session locking protocol
07:41 pstch: I'm trying to design some form of secure password prompt, in an overlay layer-shell surface with a transparent background
07:43 soreau: is a transparent background secure if sensitive information could potentially show through?
07:45 fluix: it's a prompt, not a lockscreen
07:52 leon-p: pstch: are you writing a layer-shell pinentry? Because then I have some prior art: https://git.sr.ht/~leon_plickat/wayprompt
07:52 leon-p: whether your surface gets keyboard focus is compositor policy
07:52 leon-p: you could watch for keyboard enter/leave events and maybe indicate in the UI whether your surface has focus
08:44 pq: DemiMarie, Weston definitely has (had? there has been some very recent work on the area) damage handling bugs that cause excessive texture uploads from wl_shm buffers which is definitely expensive.
08:45 MrCooper: emersion: heh, "that's not the issue" and then goes on to describe what could be explained by that issue :/
08:45 pq: Like, a simple surface move can cause a texture re-upload even without any damage. Would be worth re-testing on latest RC release, I think.
08:50 pq: Louvre has written a benchmark I have wanted to see for years. :-)
08:50 Ermine: Looks interesting
08:51 pstch: leon-p: well it is compositor policy if there is no protocol that provides it, but there were proposals for input inhibition
08:52 pstch: soreau: I mean secure as "the password cannot be stolen" not "hiding other screen contents"
08:54 pq: pstch, IOW, a globally modal dialog.
08:56 pstch: leon-p: yes I've looked at that :) but I'm afraid that its focus could be stolen by other apps
08:58 pstch: pq: yes and no, as I also want to dim the background (everything other than the dialog), and prevent other apps from stealing focus (by opening a new window)
08:59 pq: that's a globally modal dialog, indeed
08:59 pstch: dimming the background is to prove to the user that we are not an impersonating app, as fullscreen windows can't show a transparent background
08:59 soreau: so says the spec, hehe
08:59 pq: There is also the concern of an app locking out the user from their machine by displaying a globally modal dialog, which even without any malice can be annoying (cannot rearrange other windows in order to see what you want to answer the dialog). This is usability trade-off.
09:00 pstch: because of that, I think I need to use layer-shell, and combine that with the upcoming security-context protocol
09:00 pstch: pq: yes I've thought of that, but it's not a problem in my case
09:01 pq: ok
09:01 pstch: ah but maybe I'm wrong in thinking that I need input inhibition..
09:01 pstch: if I display a surface using layer-shell, in 'overlay', and no other app can use layer-shell, then no other app can steal the focus, right ?
09:02 pq: pstch, you mean you have a plan how to disallow random apps from using your dialog for random things?
09:02 pstch: pq: yes
09:03 pstch: all other apps would be sandboxed in that case, using a combination of kernel namespaces and wayland's security-context protocol
09:03 pq: cool
09:04 pq: A much more Wayland'y design would be to have an extension saying "This window is a passphrase input dialog." than trying to piece together a new use case from existing extensions that were perhaps never meant to be used that way. After all, Wayland design aims for policy, not mechanism, as much as possible.
09:05 soreau: I typically think input inhibiting in terms of compositor bindings. If you have something bound to KEY_A and that's part of the password or unlock sequence, input inhibition can be convenient
09:05 pstch: I'm just not sure how I can ensure that during the execution of the password prompt no other app can have access to input events (e.g. by stealing focus)
09:05 pq: OTOH, if you're just making an ad hoc system off what you happen to have, it's fine.
09:05 soreau: but also, what if you want to grab a new keybinding and ignore all compositor bindings from getting in the way?
09:06 pstch: pq: ah right, yes that would be an interesting thing to do. OTOH, prototyping using existing protocols can help define a future extension
09:06 pq: these questions around input inhibition are a good example: you're trying to figure out what all things you need to do in a client in order to stop a compositor from doing the wrong thing. If that responsibility was put onto the compositor instead, you would not need to guess what all is enough.
09:07 pq: oh, prototyping, sure
09:07 pstch: yes, very true
09:08 pq: although... what's there to prototype? If the protocol ends up being completely different, what did the prototype give you?
09:08 pstch: but still a bit frustrating that the screen-locking protocol seems to do everything I need, except that... I don't want to lock the session
09:08 pq: heh
09:09 pstch: I've been prototyping using the replacement for input-inhibition (screen-locking), and for now just assume my process wont crash
09:09 kchibisov: pstch: compositor is the one responsible for given focus.
09:09 kchibisov: also, layer-shell surface grabbing keyboard usually can't lose focus.
09:09 kchibisov: if it's on overlay, etc.
09:09 kchibisov: it's also all up to compositor policy.
09:10 pstch: kchibisov: right, but as I understand, there are protocols (and extensions) for asking the compositor to do that
09:10 kchibisov: and you have namespaces.
09:10 kchibisov: i don't know if there's a single one.
09:10 pstch: kchibisov: this "usually" is what I want to investigate
09:11 kchibisov: I mean, you can't protect against broken protocols.
09:11 kchibisov: you can't also protect against user having access to /dev/input.
09:11 kchibisov: if you know how to protect against user being in /dev/input, clearly you control a lot for your user already.
09:12 pstch: but users don't have access /dev/input do they ?
09:12 kchibisov: I can add myself to input group.
09:12 kchibisov: some users add themselves to it.
09:12 pstch: oh right, but by "users" here I mean sandboxed apps, which would be running using defined privileges
09:13 kchibisov: but sandboxed apps shouldn't have access to special protocols anyway.
09:13 pstch: they won't
09:13 kchibisov: then you don't have focus steeling.
09:13 pstch: ah right. I was confused.
09:13 kchibisov: And it's again a compositor policy.
09:14 kchibisov: usually compositor gives focus to a newly created window.
09:14 kchibisov: on the same workspace.
09:14 kchibisov: basically how wl-clipboard.
09:14 pstch: yes, this is the kind of issues I want to protect against
09:15 kchibisov: only compositor can protect against that.
09:15 pstch: as some existing protocols mandate that the compositor must not open new windows (or give them focus)
09:15 pstch: hmmm that's very unclear
09:16 kchibisov: I mean, why pinentry should prevent me to open window.
09:16 kchibisov: sounds like I won't use this pinentry.
09:16 pstch: because if a new window can be opened it would be able to steal input events from the pinentry ?
09:16 kchibisov: but I need a new window to get a password.
09:17 kchibisov: because I don't know it.
09:17 kchibisov: I can only fetch it, but I don't know my passwords.
09:17 pstch: in this case, it's a disk decryption password that would not make sense to store on the system itself
09:18 kchibisov: disks are decrypted usually early on.
09:18 kchibisov: without any compositor running.
09:18 pstch: not in this case
09:18 kchibisov: unless you mount an encrypted disk.
09:18 kchibisov: but why wouldn't I store key in my keychain?
09:19 kchibisov: Like I'm not sure what your use case is with focus steeling.
09:19 kchibisov: if user typing manually they are not affected by it.
09:20 kchibisov: so you likely trying to handle paste from clipboard focus stealing?
09:20 pstch: because it's the key for a layered plausibly-deniable encryption system, and the password being stored somewhere it would break the plausible-deniability of the data
09:20 kchibisov: So you type it manually?
09:20 pstch: why would users typing manually not be affected by it ?
09:20 kchibisov: because they don't see a responce that they type?
09:20 pstch: at that point it's already too late
09:21 kchibisov: one character leaking is too late for a massive password?
09:21 pstch: yes
09:21 pstch: because in my threat model, I need to protect the information of the existence of the password
09:22 pstch: if one character leaks, we know that there is a password starting by a specific letter
09:22 kchibisov: and how does it know whether it's a password or user just slammed a keyboard?
09:22 pstch: then the user can be coerced to provide that password, thwarting the efforts made to preserve the plausible deniability of the data unlocked by the password
09:23 kchibisov: Do you control compositor?
09:23 pstch: yes
09:23 kchibisov: then never give focus to anyone.
09:24 pstch: well when the password prompt is not in use, I still want the user to be able to open new applications and let the compositor give them focus
09:25 kchibisov: Define a layer-shell namespace where you never transfer focus to anyone.
09:25 pstch: both the input-inhibition and screen-locking protocols work well for my use case, except the first one is obsolete, and screen-locking... locks the screen, which is problematic in case the password prompt crashes
09:25 kchibisov: which will be a compositor policy.
09:25 kennylevinsen: pstch: screen locking also explicitly renders no other content visible
09:26 kchibisov: https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_shell_v1:request:get_layer_surface:arg:namespace
09:26 kennylevinsen: so rather than "screen locking does everything I need", it seems more like "screen locking does one thing (focus stealing) that I need" :)
09:26 kchibisov: if it's "pinentry" your compositor never transfers focus out of it.
09:26 pstch: kennylevinsen: yes, with screen locking the "dimmed background" needs to be implemented using a screenshot, indeed
09:27 kchibisov: Like if you control all the stack it's already possible to do what you want.
09:27 pstch: kchibisov: oh that's very interesting, I missed that feature of layer-shell
09:28 pstch: I also missed that : https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:enum:keyboard_interactivity
09:28 emersion: a keyboard-interactive overlay layer surface will keep focus
09:29 kchibisov: Can't you still with another overlay layer-shell?
09:30 pstch: kchibisov: in my case it's not a problem, as adversaries cannot use layer-shell
09:30 pstch: right so I was just worried for nothing about focus stealing since layer surfaces already protect me from that
09:30 pstch: thanks for your help everyone
09:31 kennylevinsen: kchibisov: yes, other clients from a higher layer will get priority - or if you get in front of the current surface on the same layer
09:31 pstch: (all this protocol/extensions definition and specification is absolutely beautiful to me)
09:31 kchibisov: yeah, so you need some policy for such case as well.
09:31 kennylevinsen: but yeah, layer-shell is meant to be privileged anyhow, and doesn't have protections against other layer-shell users
09:32 kchibisov: but if they don't expose layer-shell it's likely fine...
09:34 pstch: is a protocol being privileged something that is defined in the protocols themselves ?
09:34 pstch: or is i
09:34 pstch: or is it compositor policy to define which protocols are privileged ?
09:34 emersion: it's mostly compositor policy
09:35 emersion: some protocols have a warning "hey btw this proto is pretty dangerous if free-for-all"
09:35 kchibisov: Can you have a priv. protocol in xdg/wp namespace?
09:35 pstch: layer-shell doesn't, unfortunately
09:35 emersion: keyboard-shortcut-inhinit is… somewhat privileged but not really
09:36 emersion: maybe some compositors want set_fullscreen to be privileged
09:36 emersion: (as in, require something in the app manifest to allow fullscreen)
09:37 kchibisov: Ah, there's no serial in those requests.
09:38 kchibisov: So the app can fullscreen/unfullscreen in a loop.
09:38 pstch: so I wager a possible future extension of security-context would be to allow specifying the set of protocols available in the context ?
09:40 kennylevinsen: pstch: why would that be needed? the compositor controles what protocols it exposes
09:40 kennylevinsen: and there's a mechanism to filter globals
09:40 kennylevinsen: (wl_display_set_global_filter)
09:41 pstch: because a sandboxing engine may want to run an app and prevent it accessing some protocols
09:41 emersion: pstch: security-context is just about client identification, nothing more
09:41 emersion: the compositor is free to implement access control on top
09:41 pstch: ah, right
09:42 pstch: but then the sandboxing policy of a sandboxing engine actually depend on the compositor in use
09:43 kchibisov: Shouldn't compositor be in charge on how much to disable?
09:44 pstch: it's always in charge of everything, but it can be useful to allow the sandboxing engine to have a say in that
09:44 kchibisov: nah.
09:44 pstch: the sandboxing engine knows that an app is supposed to use some of the privileged protocols, the compositor doesn't
09:45 kchibisov: I mean, compositor just disables all of them.
09:45 pstch: all protocols ?
09:45 kchibisov: so you're stuck with just xdg-shell and that's about it.
09:45 kchibisov: and core.
09:46 kchibisov: like why would you advertise questionable protocols to untrusted clients.
09:46 emersion: at some point would be nice to allow a sandboxed app to get some select privileged globals
09:46 kchibisov: yeah, but it could be defined in compositor config.
09:46 pstch: right, so what compositors do right now is to consider everything that is not core/xdg-shell a privileged protocol that is then not exposed in security contexts ?
09:46 kchibisov: pstch: they can do whatever, it's just _they have a way_ to do that now.
09:46 emersion: i wouldn't say that
09:47 emersion: there are tons of non-privileged protos
09:47 emersion: xdg-deco, presentation-time, etc etc
09:47 pstch: kchibisov: the user of the system may want to allow a sandboxed app to access some protocols
09:47 kchibisov: pstch: write a config inside compositor.
09:47 kennylevinsen: pstch: that is possible, it's just now defined in the protocol how the compositor decides its policy
09:47 kchibisov: if sandboxed && appid == XYZ => allow layer-shell.
09:48 kennylevinsen: it could read a manifest, have its own config, etc.
09:48 emersion: there are multiple options yeah'
09:48 kchibisov: it's just the issue was to identify clients.
09:48 kchibisov: not to restrict them.
09:48 kchibisov: because if you can identify you can restrict.
09:48 pstch: but this ties the sandboxing engine to a single compositor with a compatible policy, wouldn't that be problematic with flatpak for example ?
09:49 pstch: I mean, how is security-context useful to flatpak if flatpak cannot rely on protocols not being available in the sandbox ?
09:50 kennylevinsen: it does not tie them together - any sandbox just specifies what app it runs, and the compositor decides what apps are allowed what
09:50 kennylevinsen: e.g., on sway I could have a config to allow specific apps screen share access
09:50 pstch: well this kind of policy decision is usually the role of the sandboxing engine
09:50 kennylevinsen: on gnome, you might have an option in the system config panel
09:50 kchibisov: kennylevinsen: and then our screenshare goes via dbus side channel, so security context is useless.
09:51 emersion: a lot of this hasn't been thought out yet
09:51 pstch: kchibisov: not necessarily, dbus can be isolated as well, it's just more config
09:51 kennylevinsen: pstch: not really, the final say is always in the service provider. Your sandbox might give filesystem access, but the filesystem enforces privileges. Sandbox gives wayland access, compositor enforces privileges, etc.
09:51 kchibisov: pstch: you better not see what terminals in flatpak do.
09:52 kchibisov: Like they clearly shouldn't even exist there.
09:52 kchibisov: yet we have a mechanism allowing them to 'run everything and access root'.
09:53 kennylevinsen: pstch: and while sandbox config specifies what the application *wants*, compositor specifies what the user *grants*
09:53 pstch: that depends on the system configuration, in this system I'm describing it would not be the case
09:53 pstch: ^ kchibisov
09:54 kchibisov: I just like this "No network" and "arbitrary perms" https://paste.rs/IZ4cU.png
09:55 kchibisov: like this app can do network, gain root in child process, etc.
09:55 kennylevinsen: one thing that one could consider is a way to request a not currently offered global from inside a security context
09:55 kennylevinsen: if supported and confirmed by the user, the global is then advertised
09:56 pstch: kennylevinsen: for that make sense, would'nt we also need a way to prevent global from being offered inside a security context
09:57 emersion: better just always provide the global, and then ask questions when it's used?
09:57 kchibisov: you already can do that.
09:57 kennylevinsen: pstch: wl_display_set_global_filter
09:58 pstch: that prevents from being offered everywhere, not inside a specific security context
09:58 kennylevinsen: emersion: you could, but then each protocol would need an appropriate soft error I assume
09:58 kchibisov: pstch: it's for the client.
09:59 emersion: we've been trying to always allow compositors to deny requests in our protocols
09:59 emersion: like layer shell can send closed immediately etc
10:00 kennylevinsen: pstch: it is called each time a global is about to be offered to a client
10:01 kennylevinsen: sway for example hides xwayland_shell_v1 from all clients except the xwayland instance it started itself
10:01 kchibisov: kde does the same for input_method_v2 iirc.
10:02 kennylevinsen: I wonder if clients would need to know that it failed due to privilege
10:02 emersion: kennylevinsen: why would they?
10:03 kennylevinsen: say you want to present the user with an appropriate error, or in case of layer shell fall back to an xdg window
10:03 kennylevinsen: could be obscure for the user that the application just thinks the user immediately closed the window
10:04 kennylevinsen: (well, in case of layer shell a normal close would likely be "output disconnected", but you get the idea)
10:04 emersion:shrugs
10:05 emersion: hard to say anyways, none of this exists
10:05 kennylevinsen: yup
10:08 pstch: taking a concrete example : if flatpak wanted to provide a specific permission for inhibiting keyboard shortcuts (access to keyboard-shortcuts-inhibit), it would indeed need a mechanism to ensure that the protocol is available in a security context it created
10:08 pstch: but it would also need to know that this protocol is not generally accessible, otherwise the permission cannot actually be implemented
10:10 kennylevinsen: pstch: whether an application gets permission to inhibit keyboard shortcuts is arguably user preference rather than a sandboxing decision
10:11 kennylevinsen: sandboxing is more about limiting which domains can be accessed, not enforcing fine-grained privileges (including user decisions) within those domains
10:12 pstch: ah, yes
10:14 pstch: still unfortunate for the pinentry in this sytem : it is needed that it is the only app having access to some protocols (the one enabling prompt impersonation)
10:15 pstch: ones*
10:15 pstch: of course it can be patched all of the compositors provided by the OS, but that's a lot of work
10:17 emersion: hm i'm not following
10:18 pstch: I'm trying to write an environment where the user can launch untrusted apps without fear of them impersonating the password prompt
10:21 pstch: of course, I can also chooose to only provide compositors with definitions (of which protocol is privileged) compatible with my use-case
10:21 emersion: you'll need to launch each untrusted app inside a sandbox, and then it's fine?
10:22 pstch: emersion: well that's what is done, but the sandboxing engine cannot know that layer-shell is not available *in* the sandbox, since it is an implementation detail of the compositor and neither something specified in the protools themselve nor something that can be configured for specific apps
10:24 pstch: (and this applies to all "privileged" protocols, not only layer-shell)
12:51 kchibisov: If compositor sends a wl_keyboard::keymap what happens to the modifier state it send before? Is it discarded?
12:52 kchibisov: The situation we have is that user types with virtual keyboard, but then compositor could also do input itself. So you need to change keymaps between virtual-keyboard and compositor input.
12:53 kchibisov: I think the modifiers must be resend for the focused client when you change keymaps, since they are tied to it?
18:10 DemiMarie: pstch: it sounds like you are trying to make something similar to Qubes OS. I’m a Qubes OS developer.
18:11 DemiMarie: Qubes OS use X11 right now (technical debt) but will support Wayland eventually.
18:12 DemiMarie: I recommend requiring layer shell support in the compositor. Otherwise, you won’t be able to do privileged UI (like custom menus) in a cross-compositor way.
18:24 pstch: DemiMarie: yes, Qubes has been and is a big inspiration for this project
18:25 DemiMarie: pstch: thanks! If I may ask, why not use Qubes itself? Also, have you heard of Spectrum OS (https://spectrum-os.org)?
18:25 pstch: my main focus is on the integration of the ShuffleCake LPDS in a desktop environment
18:26 pstch: yes, both were big inspirations for me
18:27 DemiMarie: pstch: ShuffleCake would be a useful addition to both, IMO. Though logs would need to be avoided.
18:27 pstch: I didn't use Qubes because I wanted tighter integration between the applications sandboxes and the host system
18:27 DemiMarie: Valid
18:28 pstch: NixOS enabled me to quickly configure an immutable-root system, and allows the use of store overlays so that software can be reused through the layers while still maintaining PD
18:29 pstch: SpectrumOS takes a much more radical approach to isolation (by defining a light custom TCB), that would make it a bit harder for me to experiment with practical uses of PD
18:30 pstch: PD is one of these things that seem really useful at first, but I find that in practice it's not easy to actually make it work
18:31 pstch: (the existence of a layer can leak through a quite formidable number of ways)
18:32 pstch: right now it's more of a toy project to see how far it's possible to go in this direction (wayland-proxy-virtwl
18:34 pstch: right now it's more of a toy project to see how far it's possible to go in this direction (AppVMs using wayland-proxy-virtwl + wayland security contexts + MergerFS + namespaced mounts and a custom GUI shell), but the practical long-term plan is to bring these changes to an existing project, so that the features can be used in a plausibly-deniable way
18:35 pstch: (using a toy OS centered around PD decreases the plausability of the denial, while one can always say that they didn't know that their sandboxed OS uses PD-storage by default, for example)
18:45 DemiMarie: This all seems really similar to SpectrumOS :)
18:49 pstch: it is, but I think there are significant differences appearing, and I do a lot of compromises that SpectrumOS's dev chose not to make