On Fri, Nov 13, 2015 at 8:40 PM, Theo de Raadt <[email protected]> wrote: >> > On 2015/11/13 09:59, Theo de Raadt wrote: >> > > > > I really want to delete telnet entirely, >> > > > >> > > > I often use it for testing unencrypted SMTP and HTTP across the >> > > > Internet. Which tool would you recommend for that purpose? >> > > >> > > nc(1). >> > I use telnet fairly often for connecting to things like crappy switches, >> > crappy routers, APs of varying crappiness, etc. nc -t isn't close to being >> > good enough for this, also with nc it's difficult to send things like ^C >> > (even worse, if you use it much you forget about this and end up killing >> > your connection). I wouldn't mind having it removed from base, but would >> > need to go in ports unless nc gets a lot of polishing. >> >> I always thought of telnet as a kind of discipline over the wire. There are >> even extensions (like RFC 2217) well-fitting discipline model. > > Like a horse buggy in the inside lane of a 4-lane highway, there are going > to fatalities. > > "discipline" applies to the user of this code -- it means "avoid any and all > unnecessary use". > >> >From other hand, nc(1) is a "raw" tool with decent client-server model. >> >> Is there any possibility to run nc(1) as a privsep server, and a telnet(1) as >> a client, talking to nc(1) server via IMSG (instead of doing network stuff >> directly)? > > What's the goal. To continue the lifetime of telne? To make the nc code > more complicated and fragile? Those are the only outcomes I see.
It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO. The goal is to delete classic telnet entirely and make it an (optional) discipline frontend for nc(1). In "telnet mode" nc(1) will only attach discipline and let user use flow control features (like ^C). It is not about extending a lifetime of telnet, it is about making telnet truly optional by making it a discipline (or flow control protocol), not a separate tool.
