openssh unix dev - Jul 2018 - trying to resurrect discussion about "Cannot signal a process over a channel (rfc 4254, section 6.9)"

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

? Thierry

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

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

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

It would indeed be really great to have some details on this point.

Concerning the test of the server side feature, it should be pretty similar to
the test of the functionality of the ~B escape character !
Unfortunately, I was unable to find any reference that such a test exists : is
anyone aware of where it could be ?

Moreover, is there any kind of guideline concerning the environment that should
be use for the test suite ?

Also in the RFC it is said :?Some systems may not implement signals, in which
case they SHOULD ignore this message? . So I think the proposed patch should
have some kind of whitelisting.

 Thanks in advance for the answers,

Yonathan Bleyfuesz

> On 6 Jul 2018, at 00:19, 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.
> 
> -- 
> Iain Morgan