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

Hi everybody

I?d like to resurrect the discussion on a known issue with the openssh server,
regarding signal delivery as described in rfc4254

This has been originally reported about ten years ago in this thread:
https://bugzilla.mindrot.org/show_bug.cgi?id=1424

I am taking he liberty to copy a few people who contributed that thread over
time

The discussion does not seem to expose the reasons that lead to the feature
being held back for so long
I do share Thomas?s feeling that separating the server and client aspects would
be a good way to restart from a clean slate

This is why I would suggest to first address the server side of the matter,
which turns out to be our team?s major and single concern here, like I believe
all/most of the other requestors

The thread contains, in Comment 44, a link to a patch here - again limited to
server side
https://bugzilla.mindrot.org/attachment.cgi?id=3120&action=edit
that we?ve been able to test on a fedora28 box, and that updated version indeed
improves the overall behaviour of the openssh server side for our needs, when
used against an python/asyncssh client side

Does it make sense for us to submit a PR on the github repo
https://github.com/openssh/openssh-portable, or elsewhere ?
or were there deeper concerns about that change that need to be further
discussed ?


Many thanks in anticipation ? Thierry

PS
I struggled a bit to get this through, so my apologies to people who received
multiple copies :)

On Thu, Jul 05, 2018 at 08:26:06 +0200, Thierry Parmentelat
wrote:
> Hi everybody
> 
> I?d like to resurrect the discussion on a known issue with the openssh
server, regarding signal delivery as described in rfc4254
> 
> This has been originally reported about ten years ago in this thread:
> https://bugzilla.mindrot.org/show_bug.cgi?id=1424
> 
> I am taking he liberty to copy a few people who contributed that thread
over time
> 
> The discussion does not seem to expose the reasons that lead to the feature
being held back for so long
> I do share Thomas?s feeling that separating the server and client aspects
would be a good way to restart from a clean slate
> 
> This is why I would suggest to first address the server side of the matter,
which turns out to be our team?s major and single concern here, like I believe
all/most of the other requestors
> 
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.

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. 

-- 
Iain Morgan

> 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