Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
72 views
Skip to first unread message
Guillem Jover
Jul 16, 2022, 10:20:03 PM7/16/22
to
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
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
Timothy M Butterworth
Jul 17, 2022, 1:50:03 AM7/17/22
to
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.
--
Jeremy Stanley
Jul 17, 2022, 8:30:04 AM7/17/22
to
On 2022-07-17 01:49:53 -0400 (-0400), Timothy M Butterworth wrote:
[...]
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
[...]
> 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
> 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.
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
Michael Stone
Jul 19, 2022, 10:10:03 AM7/19/22
to
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
>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.
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.
Philipp Kern
Jul 19, 2022, 2:20:03 PM7/19/22
to
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
Jeremy Stanley
Jul 19, 2022, 2:50:05 PM7/19/22
to
On 2022-07-19 20:15:49 +0200 (+0200), Philipp Kern wrote:
[...]
modern SSH client to successfully connect to an old device which
only speaks SSHv1 protocol?
--
Jeremy Stanley
[...]
> 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
> 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.
modern SSH client to successfully connect to an old device which
only speaks SSHv1 protocol?
--
Jeremy Stanley
Philip Hands
Jul 19, 2022, 5:20:03 PM7/19/22
to
Jeremy Stanley <fu...@yuggoth.org> writes:
...
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
...
> 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
> modern SSH client to successfully connect to an old device which
> only speaks SSHv1 protocol?
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
Sam Hartman
Jul 19, 2022, 7:50:03 PM7/19/22
to
>>>>> "Guillem" == Guillem Jover <gui...@debian.org> 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!
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!
Adam Borowski
Jul 20, 2022, 11:20:02 AM7/20/22
to
On Tue, Jul 19, 2022 at 05:43:35PM -0600, Sam Hartman wrote:
> >>>>> "Guillem" == Guillem Jover <gui...@debian.org> 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" == Guillem Jover <gui...@debian.org> 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.
> 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.
> is very much a niche application
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.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄⠀⠀⠀⠀
Michael Stone
Jul 20, 2022, 2:10:03 PM7/20/22
to
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:
>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.
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.)
Guillem Jover
Aug 5, 2022, 3:20:03 PM8/5/22
to
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
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).
Thanks,
Guillem
Guillem Jover
Aug 12, 2022, 5:40:03 AM8/12/22
to
Hi!
On Sun, 2022-07-17 at 04:18:59 +0200, Guillem Jover wrote:
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).
The described plan is implemented and all done:
> 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).
- Upload of inetutils taking over the packages and updating
alternative priority.
- Upload of netkit-telnet renaming the packages.
- Migration of inetutils to testing.
- Overrides update request filed and applied.
- Bugs files for the direct telnet/telnetd usage:
<https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=guillem%40debian.org&tag=inetutils-default-telnet-switch>
<https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=guillem%40debian.org&tag=inetutils-default-telnetd-switch>
Thanks,
Guillem
0 new messages