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 [cjwat...@debian.org]
