ControlPersist and multiple X11 forwarding.

[Damien Miller]

David Woodhouse wrote:
> I've dealt with the most important features I think are lacking in 4.2,
> but there's a few more minor things to fix yet.
> 
> - I'd like a better answer than the 'slack-fds' patch, and especially 
>   the hard-coded '+2' in it. Perhaps we should keep count of the
>   number of 'pending' file descriptors which may be opened by the 
>   channel_pre handlers at any time?

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.

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

> - The master should permit X11 forwarding for clients, even if X11
>   forwarding wasn't enabled on the original connection. While we're at
>   it, we should pass the 'forward_x11_trusted' option over the control
>   socket too.

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).

> - 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. 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.

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

-d