On Sat, Jul 16, 2022 at 10:19 PM Guillem Jover <guil...@debian.org> wrote:
> Hi! > > There's been talk about switching away from netkit-telnet and > netkit-telnetd as the default implementations for some time now, > and replacing them with the ones from inetutils, which is a maintained > project and does see releases (even though with a long cadence). > > This has been discussed somehow in #982253 and #987729. > > These packages currently use a pair of virtual packages to denote > that they are a telnet or telnetd implementation (telnet-client and > telnet-server). One problem is that currently the netkit implementations > use the generic telnet and telnetd package names, which is a clear way > to mark them as the default implementations (instead of say the other > convention of naming or providing a default-foo package). Another is > that several packages depend on these generic names instead of the > virtual packages, see below for a list that would deserve a non-blocking > "mass" bug filing, which I can handle as part of the switch. > > The inetutils-telnet recently got support for the missing «-b» option > for compatibility with netkit-telnet. > > The inetutils-telnetd and netkit-telnetd have diverging options and some > conflicting ones, but after pondering about it I don't think this should > be a major issue, as the daemon does not tend to get called by users from > scripts and similar. For completeness the divergences are these: > > inetutils-telnetd netkit-telnetd > ----------------- -------------- > short and long options short options > <missing> -D (unimplemented «exercise» mode) > -D (debug modes «auth», «encr») -edebug > -S, --server-principal -S (used to set the IP TOS) > -E, --exec-login -L > -l, --linemode <missing> > -U, --reverse-lookup -N (related but not exactly the same) > > > Simon Josefsson (CCed), who is one of the inetutils upstream maintainers, > recently adopted the netkit-telnet source package in Debian, which he'd > prefer to keep around for a smoother transition period, in case users > want or need to revert back. > > > > So, the idea would be for src:inetutils to take over the telnet and > telnetd binary packages and make them transitional packages depending > on the inetutils variants, for a smooth upgrade, and in addition also > start providing them by the inetutils-<name> packages. > > The src:netkit-telnet would then switch to ship netkit-telnet and > netkit-telnetd binary packages (this would ideally be uploaded to > experimental first, so that once ACCEPTED it can be uploaded to sid > once we start the switch, with no missing implementation in between). > > I'm inclined to do it in this order to potentially avoid two trips over > NEW, and to reduce any potential disruption period. > > In the future (after the next stable release) the telnet/telnetd > packages could be switched to be pure virtual packages, taking the role > of denoting the current default implementation, instead of introducing > default-<foo> variants, as that's what users are currently used to, and > it would keep working even if the depending packages below do not update > their dependencies. > > We'd file an override request against ftp.debian.org to get the > inetutils-telnet Priority bumped to standard to match the current > telnet package (which could get then its Priority lowered to optional). > > Currently inetutils and netkit have the same alternative priority > for telnet, I'd probably bump it also to 150 for inetutils to take > precedence. > > > If there are no objections, we could probably start working on this > switch in a couple of weeks or so. > > > > List of packages depending on telnet (but not telnet-client): > > forensics-extra (Depends) > lava (Depends) > live-task-standard (Depends) > mininet (Depends) > vland (Depends) > zssh (Depends) > > dish (Recommends against all current implementations) > lava-dev (Recommends) > lava-dispatcher (Recommends) > live-task-extra (Recommends) > pdudaemon (Recommends) > > libtelnet-dev (Suggests) > libtelnet-utils (Suggests) > procserv (Suggests) > ser2net (Suggests) > tucnak (Suggests) > > List of packages depending on telnetd (but not telnet-server): > > telnetd-ssl (Conflicts) > nyancat-server (Conflicts) > > > Thanks, > Guillem > > Telnet is old, insecure and should not be used any more. What is the point of packaging a Telnet daemon when everyone should be using SSH. Telnet Client I can see because a person may need to connect to a router or switch that is still using telnet or hasn't had SSH Certificates generated yet. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
