linux-kernel - Re: EXTPROC, telnetd LINEMODE, revisited

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87631pq2aj.fsf@basil.nowhere.org>
Date:	Fri, 11 Jun 2010 12:41:40 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Howard Chu <hyc@...as.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: EXTPROC, telnetd LINEMODE, revisited

Howard Chu <hyc@...as.com> writes:

> It's been over 10 years since I looked at this last
>
> http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0650.html

I would suggest you repost the patch.

>From a quick look it looks straight forward enough.

> Despite the fact that most people today have ready access to high
> speed broadband networking today, I think the motivation for local
> character processing is as great now as it was 10 years ago. I
> regularly use an ssh client on an Android phone to keep tabs on my
> servers when I'm away from my home base, and sometimes cellphone
> connectivity can be extremely lossy, networks can be heavily
> congested, etc... Waiting for character-at-a-time packet turnarounds
> in these conditions can be pretty aggravating. Also, if you're

I agree that it would be sometimes useful, I also had these
problems.

> unfortunate enough to need to get access to a machine while you're
> roaming away from your home network, the per-byte roaming fees can be
> murder. Both of these pain points can be minimized by using local
> character processing and only sending complete lines to the remote
> server.

I have some doubts this really needs to be implemented in the kernel.
Back in the old days it was important to save round trips
to user space because CPUs were so slow, but these days I don't think 
that's an issue anymore for mere typing.

Couldn't you implement it in screen or a similar pty based tool?

>
> Another feature with readline is a command history buffer that can be
> reviewed using Cursor Up/Down. Can/should we define this in the tty
> driver too? Or perhaps rely on the client to implement its own command
> buffer, and never mention this aspect on the wire protocol. Again,
> given the purpose, it makes most sense to me to keep this feature on
> the client side. But some coordination with the server would still be
> useful. E.g., different programs can maintain their own persistent
> command history files. It might be nice to have a way for the app to
> signal to the client which command context to use for the current
> history buffer, and keep them all separate. (Or not, I can see other
> times where you'd just rather have it all as one stack.)

e.g. history management is definitely something that should not
be done in the kernel.

> PS: if anyone knows where to send the patches for telnetd, please
> email me. Looks like the upstream source hasn't been touched since
> 2000.

I think they're defacto maintained by the distributions.

I would submit them to one of the big distributions and let
that maintainer figure it out.

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/