[Spice-devel] [spice-gtk [rfc] 0/2] Clipboard managers and Spice

[Marc-André Lureau]

Hi

On Wed, Jan 16, 2019 at 10:03 AM Victor Toso <victortoso at redhat.com> 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 at redhat.com> wrote:
> > >
> > > From: Victor Toso <me at victortoso.com>
> > >
> > > 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