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

[Ron Frederick]

On Jul 5, 2018, at 6:19 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> 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.


I’m happy to support this effort however I can, as I’ve had multiple requests from AsyncSSH users asking why this functionality doesn’t work, and the reason is usually that AsyncSSH is being used as a client to send signals to an OpenSSH server.

That said, I agree that the unit tests here would probably need to be in C, so they didn’t introduce any new dependencies. The support needed to perform unit testing should be much less work than a full client implementation, though. All that’s needed is a function to send the right SSH message, and a way to trigger that. There doesn’t even need to be any handling of responses, as the “signal” channel request is defined to not request an acknowledgement.
-- 
Ron Frederick
ronf at timeheart.net