Bug 134425 - Copy/pasting between local and remote X11 programs is broken
Summary: Copy/pasting between local and remote X11 programs is broken
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
: 141056 144067 146061 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-02 08:55 UTC by Onno Molenkamp
Modified: 2019-06-13 08:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-11-29 05:17:18 UTC

Attachments (Terms of Use)

Description Onno Molenkamp 2004-10-02 08:55:13 UTC
Description of problem:

With FC3-test2 (and also the latest development version of xorg-x11),
I can't copy/paste between programs running locally (using unix
sockets, I guess) and programs running on another host. When I'm
pasting from a remote program to a local one, the local one sometimes
hangs for a few seconds (this mainly seems to happen in KDE programs)
and then continues without having received any input.

Version-Release number of selected component (if applicable):

6.8.0-4, 6.8.1-4.

How reproducible:

Always, and with all X programs.

Steps to Reproduce:
1. ssh -X somehost (including localhost, so it's not caused by using
different X versions)
2. start X program
3. try pasting something from the 'remote' program to a 'local' program
Actual results:

Nothing happens, except a hang for a few seconds in some cases.

Expected results:

New input in the local program.

Additional info:

Pasting between two different remote programs (not using the FC3-test2
X libraries), both connected to my FC3-test2 X server, does work.

Comment 1 Onno Molenkamp 2004-10-02 19:05:06 UTC
Hm, I've started downgrading everything and it started working again
after downgrading openssh.. I don't quite understand how openssh can
only break one specific X protocol function: everything about
X-forwarding was working fine, just pasting failed.

I'm not sure whether this means it's an openssh bug and the component
of this bug should be changed to openssh, or if it's somehow an
incompatibility between xorg and openssh 3.9.

Comment 2 Warren Togami 2004-10-05 04:50:33 UTC
Does it work if you add "-Y" to your ssh options when using openssh 3.9?

Comment 3 Onno Molenkamp 2004-10-05 07:32:26 UTC
It does, thanks!

There should probably be a note about this "trusted" X11 forwarding in
the release notes because X11 forwarding is pretty useless in the
default configuration now. Currently there's only a remark about the
file permissions for ~/.ssh/config.

Comment 4 Sitsofe Wheeler 2004-11-28 20:31:25 UTC
There is a specialised case of this for emacs in bug 138617 ... Are
crashes with -X but not -Y to be filed in individual bugs for each

Comment 5 Bob T. 2004-11-29 03:08:59 UTC
*** Bug 141056 has been marked as a duplicate of this bug. ***

Comment 6 Bob T. 2004-11-29 03:12:34 UTC
Maybe if there were a hint of the existence of this "feature" in the
supplied config file, there would be some chance that we would notice it.

Comment 7 Sitsofe Wheeler 2004-11-29 08:48:34 UTC
Onno this was mentioned in the release notes - 
http://fedora.redhat.com/docs/release-notes/fc3/x86/ :

"The behavior of ssh clients that are invoked with the -X flag has changed. In
OpenSSH 3.8 and later, X11 forwarding is performed in a way that applications
run as untrusted clients by default. Previously, X11 forwarding was performed so
that applications always ran as trusted clients. Some applications may not
function properly when run as untrusted clients. To forward X11 so that
applications are run as trusted clients, invoke ssh with the -Y flag instead of
the -X flag, or set ForwardX11Trusted in the ~/.ssh/config file."

Were there some other release notes which didn't mention this?

Comment 8 Mike A. Harris 2004-11-29 12:05:56 UTC
Correct, this is not an X bug.  This is a change in the upstream openssh
default operation with X clients.  Since this may affect some users
configurations in a way that is unexpected, we made sure to document
this change of behaviour in Fedora Core release notes as mentioned above.

Thanks Sitsofe.

Comment 9 Pontus Fuchs 2005-01-07 09:08:01 UTC
*** Bug 144067 has been marked as a duplicate of this bug. ***

Comment 10 Eric Hopper 2005-01-25 01:50:29 UTC
*** Bug 146061 has been marked as a duplicate of this bug. ***

Comment 11 Eric Hopper 2005-01-25 17:34:09 UTC
For those who want to know the exact difference between trusted and
untrusted, I got this from a friendly and helpful RedHat employee.  :-)

From Ray Strode (rstrode@redhat.com)  on 2005-01-25 12:20 -------


-X means that ssh will use untrusted auth cookies for it's connections
to the xserver. 

-Y means that ssh will use trusted auth cookies.

The xauth man page describes this:
               If the trusted option is used, clients that connect
using this authorization will have full run of the display, as usual.
 If untrusted is used, clients that connect using this  authorization
 will be considered untrusted and prevented from stealing            
  or tampering with data belonging to trusted clients.  See  the     
         SECURITY  extension  specification  for  full  details  on
the               restrictions imposed on untrusted  clients.   The 
default  is               untrusted.

If you have the package xorg-x11-doc installed, then you can find the
SECURITY extension specification in 


Note You need to log in before you can comment on or make changes to this bug.