Re: [bug-inetutils] Bug report for gnu inetutils telnetd (aur: message 6 of 20)

[Chris Severance]

> Wednesday den 22 July 2015 klockan 14:36 skrev Chris Severance detta:

On Thu, Aug 13, 2015, at 01:17 PM, Mats Erik Andersson wrote:
> Hello there,
> Morally it can be argued that this failure is a good thing! 

Yes, but the other side of that coin is that Random Foo Linux should not
be less capable than any old Unix. Telnet is perfectly acceptable
through secure tunnels like IPSec VPN or SSH where the endpoints are
trusted. Some things can only connect to a telnet server because they
don't know how to speak ssh.

Arch Linux is on the leading edge where telnet is likely to be avoided.
The bug needs to be stopped before it reaches SUSE, RedHat, or CentOS.
My searches show that RPM is still on 1.9.2.

I've used this patch since I posted the bug and it's working very well.
No more disconnects before the banner.

> Could I get some detail for this claim to support a "valid change"?

When I see a <= change to an < I expect to work down the function tree
until I see some guard or adjustment code that has superseded the
changed behavior. There was no substantial code change to make this
patch transparent, only some cosmetic changes in debug lines.

> >    The return value of readstream is minimally documented. -1 seems to be
> >    an error. 0 is not obvious. 1 appears to be a flag value. 2+ seems to
> >    be a length.
> 
> On BSD and GNU/Linux, readstream() deteriorates to read(). To my
> knowledge,
> only Solaris, OpenSolaris and OpenIndiana would set HAVE_STREAMSPTY,
> thus making readstream() into anything more involved than a simple
> read().

I listed my guessed return codes because they don't seem to match with
the return codes of read. My analysis says that the return codes >0
between platforms using and not using read() will be off-by-one. Easy to
break behavior like that should be documented even if it's not
intentional. Fortunately the caller doesn't use return codes > 0. 0 is
the only value in dispute. readstream seems to have design plans for
more than the telnet server but the telnet server didn't exercise it
enough to expose the inconsistent return codes.

> At the time of this writing I am testing a patch witch does what you
> suggest and also adds code comments to clarify why the return value 0
> seems so decisive.

I can make an inetutils-git on the Arch Linux AUR if you need to develop
on the platform.