Hi On Wed, Jan 16, 2019 at 10:03 AM Victor Toso <victortoso@xxxxxxxxxx> wrote: > > Hi, > > On Wed, Jan 16, 2019 at 12:08:31AM +0400, Marc-André Lureau wrote: > > On Tue, Jan 15, 2019 at 8:11 PM Victor Toso <victortoso@xxxxxxxxxx> wrote: > > > > > > From: Victor Toso <me@xxxxxxxxxxxxxx> > > > > > > Hi, > > > > > > Several iteractions trying to avoid some bug in X11 but in the end I > > > found the iteraction with Clibpoard managers (or any other application > > > that request/set clipboard data) a bit more urgent. > > > > > > Simple try here, to not allow another application to request clipboard > > > data from guest while the user is theoretically interacting with that > > > guest machine as spice client holds the keyboard-grab. > > > > > > As pointed out by elmarco [0], that might be something desireable. So, > > > I'm introducing the possibility to enable it but have it disabled by > > > default. > > > > Iho, this kind of desktop policy doesn't belong in spice-gtk. > > Spice protocol implements this grab/request/release and who > send/receive those messages should be wary of them. It's a proxy, it shouldn't have to enforce desktop policies > > > If you don't trust the desktop, how can you trust the client > > itself? > > What? How many process do you have running in you machine? Do you > know every little thing about them? Do you expect all users to > trust every piece of software running on all target desktops? > > For all I know, browsers might run malicious javascript code that > interact with clipboard; X11 is bad by design in ta regard; In > GNOME3, GPaste running with x11 backend was able to get clipboard > data > > > Isn't it already the clipboard behaviour on Wayland? > > Why you bring 'wayland' on a generic proposal while you nack x11 > proposal by bringing 'not being generic'? To point out that this kind of decision must be enforced at desktop level, not at application level. I can imagine there are various tricks to "break" what you try to enforce here. > > > If really more secure, shouldn't it be enforced at a > > lower-level, at gtk level? > > Gtk handles application policies. Spice, in some regards, should > extend that, if the rationale here is good enough for that. May be, we need to think carefully about it. > > > In any case, I don't think this needs to delay v0.36, since > > it's not a regression. Hopefully, you agree and we can solve > > this for the next release. > > You are eager to do a release :) yes, we should do more regular releases. > I should probably have put the 'since 0.37' for the proposal but > this is jut a RFC, I wish we could discuss why this is important > instead of merging it quickly for a release or not. > > (so, yes, go ahead with the release and thanks for pushing for > that!) thanks, then I will revisit your proposal. > > > Tested on X11 and Wayland clients. > > > > > > There are more than on away to achieve this idea so feedback is welcome. > > > > > > I expect that the spice client would implement some sort to commandline > > > option like --allow-clipobard-managers to enable/disable the > > > SpiceGtkSession property on the fly. For now, there is an option in > > > spicy testing tool. > > > > > > James, would be great if you could verify if this series keep your > > > environment bug free. > > > > > > Cheers, > > > > > > Victor Toso (2): > > > gtk-session: introduce clipboard-managers property > > > > > > > gtk-session: add request targets delayed > > > > > > src/spice-gtk-session.c | 128 +++++++++++++++++++++++++++++++++++++--- > > > tools/spicy.c | 6 ++ > > > 2 files changed, 125 insertions(+), 9 deletions(-) > > > > > > -- > > > 2.20.1 > > > > > > > > > -- > > Marc-André Lureau > > Victor -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel