Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?
On Sun, Feb 22, 2015 at 10:31:08PM +0000, Philip Hands wrote:
> It seems to me it needs something along the lines of this near the -X
> and -Y options' documentation:
>
> ***WARNING***
>
> -Y option is basically irrelevant as the result of Debian
> shipping a modified binary that treats -X the same way.
> You'll need to set ForwardX11Trusted to "no" if you want the
> documented behaviour that is provided upstream.
>
> *************
>
> The patch that makes this change is here:
>
> http://sources.debian.net/src/openssh/1:6.7p1-3/debian/patches/debian-config.patch/
>
> which includes mention of the fact that the change was introduced in
> order to close this bug:
>
> https://bugs.debian.org/237021
>
> where Colin states in Message #47:
>
> I think it's become clear that it's too far-reaching at this point in
> Debian's release cycle; we need time to prepare the rest of the
> distribution for this sort of thing if it's to become the default.
>
> That was in 2004 while Sarge was (not) getting released -- we've had
> 5 complete release cycles since then, so it might be time to get rid of
> this patch.
I agree that this certainly needs better documentation, and I'll fix
that up. Apologies for not having done that sooner.
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.
debian-devel, debian-x, do you think that it's at all realistic to
expect clients to be fixed to handle such failures rather more
gracefully?
--
Colin Watson [cjwatson@debian.org]
Reply to: