Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
Hi! On Sun, 2022-07-17 at 04:18:59 +0200, Guillem Jover wrote: > 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). Ok, so given the comments, we'll be starting with the outlined plan. Thanks, Guillem
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Wed, Jul 20, 2022 at 05:15:07PM +0200, Adam Borowski wrote: Available in the archive yes, installed by default no way. That makes this current thread mostly moot, as when not installed by default (or a metapackage) you don't need any particular implementation to be blessed. I think the original email outlined why dicussion was necessary: determining which source package provides the "telnet" and "telnetd" packages. Regardless of whether they're installed by default, changing the implementation behind a binary package does warrant notice/discussion. This got derailed by additional commentary about whether they deserve to exist at all, but that's incidental to the original question. (For which, I think, there has been consensus.)
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Tue, Jul 19, 2022 at 05:43:35PM -0600, Sam Hartman wrote: > > "Guillem" == Guillem Jover writes: > Guillem> Hi! There's been talk about switching away from > Guillem> netkit-telnet and netkit-telnetd as the default > Guillem> implementations for some time now, and replacing them with > > I've reviewed your plan. Over the years I've maintained a telnet > upstream so I have some familiarity with the space even though I am no > longer involved in the telnet server universe. > I definitely think Debian should still have a telnet server, although it > is very much a niche application Available in the archive yes, installed by default no way. That makes this current thread mostly moot, as when not installed by default (or a metapackage) you don't need any particular implementation to be blessed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Loongarch's name is loong. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
> "Guillem" == Guillem Jover writes: Guillem> Hi! There's been talk about switching away from Guillem> netkit-telnet and netkit-telnetd as the default Guillem> implementations for some time now, and replacing them with Guillem> the ones from inetutils, which is a maintained project and Guillem> does see releases (even though with a long cadence). I've reviewed your plan. Over the years I've maintained a telnet upstream so I have some familiarity with the space even though I am no longer involved in the telnet server universe. I think your plan makes sense and I support it. I definitely think Debian should still have a telnet server, although it is very much a niche application Thanks Guillem and Simon for your work on this!
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
Jeremy Stanley writes: ... > This is getting increasingly off-topic, but you're able to get a > modern SSH client to successfully connect to an old device which > only speaks SSHv1 protocol? There is: openssh-client-ssh1 https://tracker.debian.org/pkg/openssh-ssh1 Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On 2022-07-19 20:15:49 +0200 (+0200), Philipp Kern wrote: [...] > I found the client-side very tolerant of ancient server-side > implementations when the right kinds of switches are passed to it > (e.g. KexAlgorithms and HostKeyAlgorithms). I have yet to be > unable to actually connect to a target - even if it means fiddling > increasingly with flags. This is getting increasingly off-topic, but you're able to get a modern SSH client to successfully connect to an old device which only speaks SSHv1 protocol? -- Jeremy Stanley signature.asc Description: PGP signature
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On 19.07.22 16:05, Michael Stone wrote: On Sun, Jul 17, 2022 at 01:49:53AM -0400, Timothy M Butterworth wrote: 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. I personally use telnet to connect to systems whose ssh implementations are old enough that they are no longer interoperable with current ssh. Every system will eventually become an old system, and telnet has a much better record of working over the long term than does ssh. Security concerns have a place in determining defaults, but not in banning software that other people find useful in a context that might not matter to you. I found the client-side very tolerant of ancient server-side implementations when the right kinds of switches are passed to it (e.g. KexAlgorithms and HostKeyAlgorithms). I have yet to be unable to actually connect to a target - even if it means fiddling increasingly with flags. Kind regards Philipp Kern
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Sun, Jul 17, 2022 at 01:49:53AM -0400, Timothy M Butterworth wrote: 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. I personally use telnet to connect to systems whose ssh implementations are old enough that they are no longer interoperable with current ssh. Every system will eventually become an old system, and telnet has a much better record of working over the long term than does ssh. Security concerns have a place in determining defaults, but not in banning software that other people find useful in a context that might not matter to you.
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On 2022-07-17 01:49:53 -0400 (-0400), Timothy M Butterworth wrote: [...] > 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. My personal interest in Telnet clients is that MUDs (multi-user network text games/worlds) are still primarily designed as Telnet servers, albeit with varying degrees of support for the many extensions to the protocol which have become somewhat standard over the years. Clean libraries capable of reliably implementing an sshd for this purpose are a relatively recent thing, so I expect to see some MUDS appear with options for SSH protocol connections (and I've been noodling on ideas in that vein), but for now pretty much everything in that space is either Telnet based or entirely bespoke. Inetutils seems to only support the RFC 2946 "encrypt" extension, but some Telnet servers and clients include direct support for wrapping with SSL/TLS socket encryption (Netkit does) or implementing Jeffrey Altman's START-TLS draft proposal. Since authentication is generally handled independently of the daemon, it can work with a variety of single or multi-factor authentication backends including certificates, one-time-passwords, and so on. Also, if you're going to provide a Telnet client, it makes sense to include at least a reference implementation of a Telnet server in order to be able to validate its functionality. -- Jeremy Stanley signature.asc Description: PGP signature
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Sat, Jul 16, 2022 at 10:19 PM Guillem Jover 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 > -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 >-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- 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- 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/ ⠈⠳⣄⠀⠀
RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
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 -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 -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- 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- 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
