ControlPersist and multiple X11 forwarding.

[David Woodhouse]

On Wed, 2005-09-07 at 20:53 +1000, Damien Miller wrote:
> The X11 multiple forwarding diff I sent you a while back handled this
> correctly. IIRC it set a flag that caused channel_prepare_select() to
> recalculate the maximum fd.

OK. I'll dig that out and take a look.

> But, like I said then: I'm not interested in multiple X
> forwarding unless we correctly do multiple agent forwarding.

It would be unfortunate for X11 forwarding to work correctly for the
clients while agent forwarding still doesn't, I agree. But to me, the
fact that X11 forwarding doesn't work as expected is _more_ of an issue
than the asymmetry which would result if it were fixed. It's better to
fix X11 alone than to fix neither.

If you _really_ think that the asymmetry is more of a problem than the
lack of separate forwarding, p'raps we could make the correct handling
of multiple X11 forwarding optional, so that it can be disabled by
default? I don't really think that's appropriate though.

> I disagree. X11 forwarding activation should be the logical AND of the
> master's setting and any slave request, otherwise you need another
> config option to disallow all X11/agent forwarding on a given connection
> (and we don't want any more config options).

How about turning the ForwardX11 option into a yes/no/never option
instead of just yes/no? Then it's not a _new_ option we're adding,
right?

Otherwise, if you want to change the semantics of the existing '-x' cor
'ForwardX11 no' setting to mean 'never', instead of just 'not for this
session', then we'd need to reconsider whether scp should be setting it
when it invokes ssh to make the connection.

Another way to fix the immediate problem would be to make scp use 
'-o ControlPersist no' when invoking ssh, so that it doesn't start up a
master with X11 and agent forwarding disabled. But I don't like that
much.

> > - Should investigate multiple agent forwarding. That's somewhat harder
> >   than multiple X11 forwarding, and may not be possible at all. But the
> >   lack of multiple agent forwarding is less of a problem than the lack
> >   of multiple X11 forwarding; at least for me.
> 
> This requires a protocol extension. 

Yes. Multiple agent forwarding can't be done with the existing protocol.

> I'd prefer to also use a protocol extension for multiple X11
> forwarding. E.g. the master gets forwarded using the current standard
> extension, slaves with different $DISPLAYs get forwarded using the
> extension. That gets us backwards compatibility.

I'm not sure I understand. With the trick of distinguishing between
displays by X11 auth data, we _have_ backwards compatibility -- the
resulting ssh client program works happily with old servers, using
multiple displays. There's no change at the server side. 

If there was a protocol extension for X11, then surely it wouldn't work
with older servers? We'd be _losing_ backwards compatibility, not
gaining it?

I'd understand (and _perhaps_ concede) an argument that we should extend
the protocol because using the authentication cookie in this way is an
ugly hack, but I don't understand why backwards compatibility is
relevant.

> Anyway, before adding features I think the multiplexing code more
> urgently needs a working escape char handler for the slave channels :)

Yeah. I was coming to that conclusion too ;)

-- 
dwmw2