00:04 DemiMarie: kennylevinsen: clipboard access extensions are a serious security risk when used with SSH, unless the clipboard content is transmitted via an out of band mechanism.
00:06 kennylevinsen: DemiMarie: see OSC-52
00:07 DemiMarie: kennylevinsen: which has known security problems
00:08 DemiMarie: When using a non-sandboxed application (which is most CLI applications), it really is more secure to connect to the Wayland compositor directly, rather than to communicate with the terminal emulator.
00:09 kennylevinsen: not sure I agree
00:10 kennylevinsen: But you have the same security issue when using e.g. waypipe, rdp, SPICE, …
00:10 emersion: the wayland socket can only grant extra privileges compared to the escape codes provided by the wayland terminal emulator
00:11 DemiMarie: emersion kennylevinsen: the difference is that the Wayland socket is only available to local applications, whereas the escape codes are available to remote applications.
00:11 kennylevinsen: I think Demi’s idea is that it would then not work over ssh, which would then of course be extremely annoying over ssh
00:11 zamundaaa[m]: Demi: unless you give all apps clipboard access all the time, you can't make that work
00:11 zamundaaa[m]: You need a focused surface to get clipboard access, which terminal applications don't have, local or not
00:11 emersion: i mean… the whole point is to make it work over ssh
00:12 DemiMarie: emersion: seriously?
00:12 DemiMarie: that was not at all what I was expecting
00:12 emersion: the whole point of OSC-52, yeah
00:12 DemiMarie:is very, very surprised
00:12 emersion: (and also make it WSI-independant, i suppose)
00:12 emersion: (but CLI apps have long just invoked xclip and such)
00:13 DemiMarie: to me, the best solution is to replace the old terminal with an explicit protocol
00:14 DemiMarie: kennylevinsen: breaking clipboard access over SSH is the point. I don’t want remote applications to have clipboard access.
00:14 DemiMarie: More specifically, I don’t want them to have implicit clipboard access.
00:15 DemiMarie: My usual assumption with SSH is that the remote host is less trusted with the local one and should not be able to access the user’s clipboard without user confirmation.
00:15 DemiMarie: That said, this is a valid difference in threat model.
00:16 emersion: you grant any webpage clipboard access
00:16 emersion: ssh is not very different here
00:16 zamundaaa[m]: Demi: like I said, you can't do that without opening up more security holes in Wayland
00:16 mclasen: who knows what you grant a webpage nowadays...
00:16 zamundaaa[m]: If there's issues in how terminal emulators grant access to the clipboard, then those issues have to be fixed
00:16 DemiMarie: emersion: I believe I don’t, actually. I disable that via a Chrome policy.
00:17 emersion: you can disable OSC-52 in the same way
00:17 DemiMarie: emersion: what I would like (and was very easy with X11) is to have it enabled for local apps _only_.
00:18 emersion: i don't see how wayland changes things
00:18 DemiMarie: emersion: `wl-clipboard` not working would be annoying
00:18 DemiMarie: but this is also a very valid difference of opinion
00:18 emersion: i don't understand
00:19 DemiMarie: zamundaaa: I would use security-context to restrict sandboxed apps while unsandboxed apps have full access.
00:19 emersion: you want to make OSC-52 not work? and you're talking about wl-clipboard, which isn't used by OSC-52?
00:19 mclasen: there seem to be two opposing opinions here
00:20 emersion: disabling OSC-52 would be done by configuring the terminal emulator
00:20 emersion: or is it something else that you want?
00:20 DemiMarie: emersion: if wl-clipboard doesn’t work, then OSC-52 is the only way (that I know of) for a _local_ Wayland application to access the clipboard, but that is also available to _remote_ Wayland applications.
00:20 mclasen: 1) osc 52 makes the clipboard accessible to remote apps - bad
00:20 mclasen: 2) xclip makes the clipboard unconditionally accessible to any local app - good
00:20 mclasen: at least that is how I understand what DemiMarie is saying
00:20 DemiMarie: mclasen: all _unsandboxed_ local apps
00:21 DemiMarie: to me, there is no point in protecting from something that could write to ~/.profile.
00:21 mclasen: there's no sandboxing in X to limit that
00:21 DemiMarie: mclasen: am I being confusing here?
00:22 DemiMarie: My assumption is that sandboxed apps don’t have X11 access.
00:22 mclasen: yes, if your compositor does the security contex thing, you could make that distinction
00:22 DemiMarie: exactly!
00:23 mclasen: I don't think it is very useful
00:25 emersion: it allows GNOME to reliably identify apps asking to intercept global compositor bindings
00:25 emersion: even for GNOME, it is useful
00:25 emersion: (for non-GNOME, it's even more useful)
00:26 mclasen: we'll use a portal
00:26 emersion: even then, it allows GNOME to reliably identify apps setting their xdg_toplevel.app_id
00:27 mclasen: there's great utility in being able to identify apps
00:27 mclasen: but I don't see why my compositor needs ot be involved in that
00:27 mclasen: the only reason would be to pretend that dbus doesn't exist
00:28 emersion: thanks for the productive comments
00:28 emersion:checks out
00:28 mclasen: but we can agree to disagree on that
00:29 Company: are we doing nesting of security contexts?
00:30 Company: the biggest problem with all of this is that in the mind of users, "the clipboard" is a global thing
00:31 Company: so whatever method anyone comes up with for securing it will be unintuitive because it breaks that assumption
00:35 Muzer: cheers for the pointers, I've patched out the checks in kwin so now I can have the X clipboard work as it did in X :)
00:35 Muzer: works a treat
00:37 Muzer: incidentally to add to the debate, FWIW I use ssh x forwarding at work. Literally the only reason I do this is to get clipboard integration between my remote vim instance running on a Linux server and my work-issued Windows machine (via WSL), along with the occasional command-line use of xclip
00:44 DemiMarie: Company: you can ask Qubes OS how to de-train users of that assumption
00:44 Company: I don't think users want to be de-trained
00:44 YaLTeR[m]: arguably if you're using a system that clearly puts security front and center, you're already expecting things to not always work
00:45 Company: the first interop thing everyone always does is make the clipboard work
00:45 DemiMarie: YaLTeR: that is somewhat true, but we work hard to make as much work as possible.
00:45 Company: so you can copy/paste into/out of your vms
00:46 zamundaaa[m]: Company: that's not really true actually, spice-vdagent doesn't have any Wayland support yet
00:47 zamundaaa[m]: It only works on Gnome because it gives X11 apps unconditional access to the clipboard
00:47 DemiMarie: Qubes OS does have a global clipboard, but access to it is explicit, not implicit, which solves the security problems.
02:30 DemiMarie: Regarding enums: could there be an on_out_of_range attribute in the XML, which would both specify that out of range values are a protocol error and specify the specific error to use?
19:17 wlb: wayland-protocols/main: Simon Ser * xdg-shell: clarify clients set their initial state before initial commit https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/b4a42c88f49d stable/xdg-shell/xdg-shell.xml
19:17 wlb: wayland-protocols Merge request !333 merged \o/ (xdg-shell: clarify clients set their initial state before initial commit https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/333)
19:41 Muzer: <YaLTeR[m]> arguably if you're using a system that clearly puts security front and center, you're already expecting things to not always work <-- indeed but since Wayland is being touted by distros as a general-purpose replacement for X I don't think most users would perceive it as "putting security front and centre", or even want that when it involves compromising functionality. After all, realistically for most people, if someone has access to your user,
19:41 Muzer: it doesn't matter whether or not they have access to the clipboard, it's pretty much game over. You can do all sorts of damage with someone's browser cookies without even having to know their passwords. So with this in mind this particular brand of clipboard security seems particularly obtuse to me... which is why I patched it out :) given kwin already has user-configurable options for allowing X apps global access to the keyboard, I think I might try to
19:41 Muzer: upstream a config option to the same effect for the clipboard.
19:41 YaLTeR[m]: I was talking about qubes os
19:42 Muzer: ah sorry
19:42 Muzer: I saw that message but didn't make the contextual link
19:46 kennylevinsen: well, any general purpose OS must put security front and center, QubesOS just takes that further and makes tradeoffs that the average user might deem unacceptable
19:47 kennylevinsen: variation is good though - people have different tastes, preferences, and (in case of security) things to worry about
19:47 Muzer: absolutely agreed
19:50 Muzer: for the example of my work usage of the X11 clipboard especially - if someone external has access to my X forwarding session that's already a horrendous security breach that could have huge implications. The fact that they can also get access to the code/log lines/whatever I'm copying between Windows and the remote development server is so far down my list of priorities at that point that I'm not really willing to make any usability sacrifices to prevent it...
19:50 Muzer: (of course you could argue that's a moot point as I suspect this sort of use case is going to be one of the last hold-outs of X over wayland, but whatever)
19:51 kennylevinsen: note that there is a difference to variation vs. adding big toggles to change fundamental behavior
19:51 kennylevinsen: if compositors in general had a "security off" button, apps would start getting written to require security to be off, and then users would no longer be able to use their system with security on, making it all for nothing
19:52 Muzer: perhaps it's my imagination but I've always found KDE to be fairly keen on its big toggles for fundamental behaviour, by comparison to other desktop environments
19:52 kennylevinsen: Those toggles are not fundamental behavior, they're just preferences
19:53 Muzer: what is really the difference here between what I'm proposing and the existing toggles for allowing legacy X apps global access to the keyboard and mouse?
19:53 Muzer: because that toggle already exists
19:53 kennylevinsen: Toggles for fundamental behavior is like compiling your kernel without filesystem permission support, so everything is free for all
19:54 kennylevinsen: there's a big difference between *that*, and changing between single-click or double-click, moving your systray, changing your fonts, etc.
19:55 kennylevinsen: The KDE toggle for global keyboard and mouse access is already a very special workaround that I don't think anyone else has - and I don't think KDE *wants* to have it either, I imagine it's just temporary
19:55 kennylevinsen: but I can't comment on that
19:57 zamundaaa[m]: With the adoption rate of the global shortcuts portal, "temporary" will be a long time. But yes, it's not supposed to stick around forever