[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Colin Watson <cjwatson@debian.org> writes:

> I tried some experiments with ForwardX11Trusted=no today, and frankly,
> it doesn't even pass the laugh test for usability.  Run xterm and try to
> select something, bam, your xterm crashes with BadAccess.  Now, sure,
> that's telling me that the X SECURITY extension forbids writing to the
> selection, but giving client software a chance to catch up with the
> expectation that it should handle such errors is exactly the kind of
> reason that I chose to deviate from the upstream default in the first
> place!  Now, I didn't do very exhaustive testing or anything, but to me,
> those ten years haven't actually made a perceptible difference to how X
> clients respond to failures from the SECURITY extension.

> If I thought that this was actually useful, it might be worth the pain.
> But at least I'm not the only one who thinks that this is a dubious
> benefit for the pain it brings:

>   https://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html

> So: I don't think that this decision is realistically just up to me.  If
> I change ssh back to use ForwardX11Trusted=no by default, a bunch of
> other maintainers are going to be asked to fix their software in various
> ways: the SECURITY extension may say no to something, but you might
> reasonably expect that double-clicking in your terminal won't make it
> explode in your face.

Yeah, I think I agree.

It would be great if X supported two different types of X forwarding:
trusted and untrusted, with apps working in untrusted mode but with more
restricted privileges.  Should that ever become the case, that would be a
great feature to enable.

However, right now, there are two different types of X forwarding: the one
that works, and the one that causes X apps to crash randomly.  Or, in
other words, "doesn't work."  If you want X forwarding that doesn't
actually work, just don't use the -X or -Y option at all, and you'll have
a much better error message.

If someone felt excited about doing the work required to make this feature
usable, it sounds like there's lots of low-hanging fruit in the form of X
programs that could be taught to support the X11 SECURITY extension.

In the meantime, everyone uses ssh -X to forward an X connection that will
actually work, and has adjusted to the fact that this grants a lot of
power to the remote system.  (I've been hearing warnings about being very
careful with what hosts you use -X with for something like 15 years.  It's
not old news.)  I've rarely met someone who even knew -Y existed, let
alone used it.

If there were a real feature benefit, the backwards-incompatibility may be
worth it, but given that the feature doesn't actually work, meh.  It's
hard to get particularly excited about doing work to try to enable it, and
it feels really dubious to do it by breaking the command-line option
everyone is used to using.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: