Hi,
I discovered when using my fuse fs for connecting to a remote host
using sftp that the new
server version 7.4 sends a greeter which is not according the format desribed in
https://tools.ietf.org/html/rfc4253#section-4
There is written that the greeter "MUST be terminated by a single
Carriage Return (CR) and a single Line Feed (LF) character (ASCII 13
and 10, respectively)."
Now the greeter send by openssh 7.4 looks like:
00000000 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f |SSH-2.0-OpenSSH_|
00000010 37 2e 34 0a
|7.4.|
00000014
As you can see the greeter is terminated by "0a", which is a linefeed.
The carriage return is not there.
Stef Bon
2017-02-04 13:06 GMT+01:00 Stef Bon <stefbon at gmail.com>:> Hi, > > I discovered when using my fuse fs for connecting to a remote host > using sftp that the new > > As you can see the greeter is terminated by "0a", which is a linefeed. > The carriage return is not there. >Hmm, this is remarkable. Following RFC's strictly is one of the rules when developing software. This bug is reproducable always. Nobody interested? Stef
On 2017-02-05 at 19:57 +0100, Stef Bon wrote:> Hmm, this is remarkable. Following RFC's strictly is one of the rules > when developing software.Without taking a stance on this particular issue reported against OpenSSH: No, following RFCs is a good default stance, unless and until you have a good reason to do otherwise. RFCs are not laws and they're not flawless. Sometimes it's right to break them. I'm one of the maintainers of Exim. That software handles a lot of mail. Sometimes we provide options to ignore RFC limits or act against them. Sometimes we make the default be explicitly against RFC and provide an option for folks to be compliant if they really want. Good engineering involves analysis of consequences and making judgement calls, not just doing whatever someone else managed to get written down.> Nobody interested?It's the weekend. You mailed on a Saturday and are chasing on a Sunday, disappointed that nobody has jumped on it already? Wait a couple more days before making such conclusions, let the OpenSSH maintainers have a chance to (1) enjoy their weekends, stress-free; (2) get around to it sometime in the week. If you want 24x7 support, you generally need to _pay_ for it. -Phil
On Sat, Feb 04, 2017 at 01:06:07PM +0100, Stef Bon wrote:>I discovered when using my fuse fs for connecting to a remote host >using sftp that the new >server version 7.4 sends a greeter which is not according the format desribed in > >https://tools.ietf.org/html/rfc4253#section-4 > >There is written that the greeter "MUST be terminated by a single >Carriage Return (CR) and a single Line Feed (LF) character (ASCII 13 >and 10, respectively)." > >Now the greeter send by openssh 7.4 looks like: > >00000000 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f |SSH-2.0-OpenSSH_| >00000010 37 2e 34 0a > |7.4.| >00000014 > >As you can see the greeter is terminated by "0a", which is a linefeed. >The carriage return is not there.It was probably because of this commit: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.472&r2=1.473 Which removed support for protocols older than 2 but perhaps failed to account for the fact that newline had been redefined when using protocol 2. But as someone else said, give it a few days for a response. Mike Stone
2017-02-05 23:12 GMT+01:00 Michael Stone <mstone at mathom.us>:> > It was probably because of this commit: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.472&r2=1.473 >Yes here the combination cr and lf is removed.> Which removed support for protocols older than 2 but perhaps failed to > account for the fact that newline had been redefined when using protocol 2. > But as someone else said, give it a few days for a response.Sure. I reacted not to make you hurry, but for me an error in the greeter (as in the whole init and negotiation phase) is crucial. And I think not only my software, but others too. Error's have to be reported as soon as possible, since openssh is widely used a lot and important to many. Thanks a lot, Stef