Hi
----- Original Message -----
> >
> > Hi
> >
> > ----- Original Message -----
> > > On Thu, Jan 11, 2018 at 12:35:36PM -0500, Marc-André Lureau wrote:
> > > > > I agree with you that some help from the windowing/toolkit would be
> > > > > good
> > > > > to have, but in this case, I doubt we are going to be able to do
> > > > > better
> > > > > than managing this in spice-gtk.
> > > >
> > > > Yet it is already being solved at a lower level, where you can actually
> > > > enforce that behaviour.
> > >
> > > Yes, it is solved with wayland. The question I'm asking/the problem I'm
> > > trying to solve is what do we do for existing systems using Xorg and
> > > gtk+3. With Xorg being phased out (which will still take a few years),
> > > and gtk+3 being phased out (again, will take at least a few years), I
> > > don't see this kind of clipboard behaviour changes going into either of
> > > these. Maybe I'm wrong, but assuming I'm not, then either we fix it
> > > ("it" being xorg + gtk3) in spice-gtk even though that's not the best
> > > place, or we don't fix it at all.
> > >
> > > If we decide to do something in spice-gtk, one option is to only send
> > > the clipboard when the window is focused, which will reduce the attack
> > > surface for everyone, and hopefully will have minimal impact.
> > > Another option (which is not exclusive) is to add command-line/runtime
> > > ways of enabling/disabling clipboard sharing, which you will either have
> > > to know about it if it's enabled by default, or will be quite disruptive
> > > if we disable clipboard sharing by default.
> >
> > Is it really a security reason the clipboard behaviour is different on
> > Wayland? For me, this "share on focus" is not a more secure behaviour.
> >
>
> The bug report explains in more detail the use case.
> Is describing an administrator user with different client opened sometimes
> having to copy&paste some password with tools like keepass.
> These tools usually clear the clipboard after some time.
> Yes, in this case the user would be better not to be connected to VMs
> and surely having clipboard support disabled is safer but for security
> clipboard should be disable by default, not with an option.
Yes, disabled by default
> Considering that this is considered low impact a workaround like the
> focus limitation is enough.
> One more good thing also about the focus limitation is that if you
> keep multiple VM connected but you don't interact with them you
> don't send clipboard messages potentially reducing th network usage.
very marginaly (it's not the content)
> > >
> > > I'd lean towards doing "clipboard sharing for focused client" +
> > > "command-line/runtime option, with clipboard sharing enabled by
> > > default".
> >
> > I'd rather stick with a simple command-line & runtime option.
>
> Not so simple considering that you have to patch different tools
> (boxes, virt-manager, virt-viewer) while just changing spice-gtk
> would be a single patch.
Disabling by default, and command line option is in spice-gtk.
Yes, a UI change is needed in the clients, but I believe that will be needed anyway to secure it.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel