trying to resurrect discussion about "Cannot signal a process over a channel (rfc 4254, section 6.9)"

Iain Morgan imorgan at nas.nasa.gov
Fri Jul 6 08:19:56 AEST 2018


On Thu, Jul 05, 2018 at 23:42:55 +0200, Thierry Parmentelat wrote:
> 
> > At one point, I had wondered about separating out the client and server
> > support as well. At first glance, that would seem to help move things
> > forward and would address most of the reported use cases. However, I
> > have some users who would need the client support as well.
> > 
> > I suspect that adding the server support first might be a problem for
> > the developers. Such a feature would need regression and unit tests, and
> > those would be easier to implement if the client has support for the
> > feature.
> 
> Fair enough, but apparently having to swallow both aspects in the same move seems to have proven too big a bite at least once :)
> I am not at all familiar with the openssh codebase, but if that helps and if that sounds like a doable idea, we can certainly propose to provide some dedicated test stubs addressing the server side, written e.g. in asynchronous python based on asyncssh, that at first sight has all that is needed to carry out fine-grained tests in this area; even if temporarily, i.e. until some agreement can be found on what the client side should look like
> 
> > It would be nice to know what the precise technical issues are that have
> > prevented support for this from being added. From what I recall, it
> > seemed like the delay was largely due to details of the client
> > behaviour, and possibly some feature creep. 
> 
> agreed ! the initial thread was not exactly very talkative on all this..
> 

One thing to keep in mind is that OpenSSH is primarily developed on
OpenBSD. Any test suite would need to work on a base OpenBSD install,
which does not include Python. Of course, the test suite would need to
work on other platforms as well.

-- 
Iain Morgan


More information about the openssh-unix-dev mailing list