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@xxxxxxxxxxxx> 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
