#881626 busybox: enable telnetd

Package:
busybox
Source:
busybox
Description:
Tiny utilities for small and embedded systems
Submitter:
Luca Boccassi
Date:
2022-01-18 01:09:03 UTC
Severity:
wishlist
Tags:
#881626#5
Date:
2017-11-13 17:16:26 UTC
From:
To:
Dear Maintainers,

Please consider enabling telnetd in the busybox package. A tiny and
trivial patch to set the config is attached inline. A rebuild with that
change seems to work fine.

As much as I wish it wasn't the case, telnet is still widely used,
especially in the ISP/telco world. Telcos networking engineers expect
to be able to telnet into boxes in their network even today.

Having telnetd available without having to rebuild busybox would be
extremely handy when using Debian (or derivatives) in small boxes (eg:
arm64) inside a telecommunication provider's network.

Thanks!
---
 debian/config/pkg/deb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/config/pkg/deb b/debian/config/pkg/deb
index 290205d99..73428dc5b 100644
--- a/debian/config/pkg/deb
+++ b/debian/config/pkg/deb
@@ -903,8 +903,8 @@ CONFIG_TELNET=y
 CONFIG_FEATURE_TELNET_TTYPE=y
 CONFIG_FEATURE_TELNET_AUTOLOGIN=y
 CONFIG_FEATURE_TELNET_WIDTH=y
-# CONFIG_TELNETD is not set
-# CONFIG_FEATURE_TELNETD_STANDALONE is not set
+CONFIG_TELNETD=y
+CONFIG_FEATURE_TELNETD_STANDALONE=y
 # CONFIG_FEATURE_TELNETD_INETD_WAIT is not set
 CONFIG_TFTP=y
 # CONFIG_TFTPD is not set
-- 
2.11.0
#881626#10
Date:
2017-11-14 12:50:52 UTC
From:
To:
As much as I don't mind doing weird things in support of weird use
cases, in this particular case I think that would be sending out the
wrong message. We shouldn't do that, IMO, but rather encourage people to
switch to SSH instead of telnet.

It might make sense to add some documentation that explains why telnet
isn't supported, however.

As an aside, can you tell which telco's we are talking about?
#881626#15
Date:
2017-11-14 13:05:49 UTC
From:
To:
I wish that could happen, I swear. Having to support it is just...
"fun". :-(

We tried. Everybody knows it's bad, insecure, generally horrible and
all that. But at the very least until all the network operators trained
by a certain network hardware vendor will retire demand for telnet is
not going away, sadly. I wish I could do anything to change that.

Right now it's an North American provider with a three characters name
;-) But I've yet to find one telco that doesn't demand telnet,
unfortunately. They are not alone in that.

Thanks!
#881626#20
Date:
2017-11-14 12:50:52 UTC
From:
To:
As much as I don't mind doing weird things in support of weird use
cases, in this particular case I think that would be sending out the
wrong message. We shouldn't do that, IMO, but rather encourage people to
switch to SSH instead of telnet.

It might make sense to add some documentation that explains why telnet
isn't supported, however.

As an aside, can you tell which telco's we are talking about?
#881626#25
Date:
2017-11-14 13:20:25 UTC
From:
To:
Busybox upstream does that in https://busybox.net/tinyutils.html
Which has a pointer to http://matt.ucc.asn.au/dropbear/

Text from the homepage of dropbear

  Dropbear SSH

  Dropbear is a relatively small SSH server and client. It runs on a
  variety of POSIX-based platforms. Dropbear is open source software,
  distributed under a MIT-style license. Dropbear is particularly useful
  for "embedded"-type Linux (or other Unix) systems, such as wireless
  routers.


That in other words:

  There is an alternative for telnetd

  There is NO need to keep sending clear text passwords ...



Groeten
Geert Stappers
#881626#30
Date:
2017-11-14 18:35:14 UTC
From:
To:
Anything that makes it more work for you and hence gives more incentive
for you to get the clueless people that want to keep using telnet to
change is a good thing.  Allowing telnet access ought to be made as
difficult as possible.

People have been saying to not use telnet for about 20 years now.
They better have learned by now.
#881626#35
Date:
2017-11-14 18:35:14 UTC
From:
To:
Anything that makes it more work for you and hence gives more incentive
for you to get the clueless people that want to keep using telnet to
change is a good thing.  Allowing telnet access ought to be made as
difficult as possible.

People have been saying to not use telnet for about 20 years now.
They better have learned by now.
#881626#40
Date:
2017-11-14 18:59:41 UTC
From:
To:
LOL.

you are aware that this would only cause (these) people to switch away
from Debian, but not from telnet?

also, I miss your removal requests for the telnetd and ftpd and
(countless) other packages.

to the original poster: what's wrong with installing telnetd? its only
103kb in size...
#881626#45
Date:
2017-11-14 19:00:35 UTC
From:
To:
Again, I wish it could work like that. Sadly, it doesn't. More work for
me just means more work for me, nothing else. The people that want
telnet will keep using telnet, if not from Debian from a downstream
fork or from a different distro or worse from a proprietary vendor.

It's not that they haven't learned - it's just that they don't care.
#881626#50
Date:
2017-11-14 19:30:59 UTC
From:
To:
I honestly believe they just haven't tried.  As long as you indulge them,
they will keep training new people with bad habits.  It won't go away
until you make it go away.  Sometimes you really do have to tell
people no.

Well at least in a separate package you don't accidentally get it just
by installing busybox.
#881626#55
Date:
2017-12-05 14:53:56 UTC
From:
To:
Sorry, but that's just not the case. Honestly, I tried, may others have
too, it's just not going to happen - either Debian provides it, or
they'll go somewhere else (or ask for the services to be based on a
different distro and so on).

Well for small systems for starters - most tools provided by busybox
are "just a few kb in size", but we still use it.

More importantly in my case, busybox telnetd is really standalone and
can do inetd work by itself, which is not the case for the standard
telnetd. So it's not just a matter of footprint, but lack of feature
too.

Even if you install it, it won't do anything unless you enable it via
an init script or by starting it manually. So there's no chance of
using it by mistake.
#881626#60
Date:
2018-04-07 16:47:38 UTC
From:
To:
that
(eg:
2001

Dear Maintainers,

Any chance this patch could be looked at?
It would really help those of us in the networking world using Debian,
and would make no difference for anybody else as there's no
service/init script to start the daemon automatically.

Thanks!
#881626#65
Date:
2019-07-22 00:14:07 UTC
From:
To:
Hi Luca,

It would be remiss of us to deliberately introduce support for a network
protocol that has no realistic prospect of secure operation. We will not
enable telnetd in any of the flavours of busybox that we currently package.

I would encourage you to build your own busybox packages if you need
this functionality, or to simply install one of the multiple available
standalone telnetd packages available in Debian.

That being said, a new flavour of busybox is under consideration that
enables all possible feature flags (within reason). Given the goal of
such a package, it would be entirely possible for telnetd to be included
in it. There is no timeline for the introduction of such a package and
every chance it might not happen, though.

Best regards,
Chris
#881626#70
Date:
2022-01-18 00:17:38 UTC
From:
To:
Respectfully, telnetd has been enabled for busybox-stable since 2010, so
you can install busybox-stable.

Maybe this is an indication that busybox-stable needs to be audited, or
that all 3 configurations should be audited to make sure something isn't
missing that has no reason to be.

(I have a few in mind already, but they deserve their own bugs)



Best Regards,
Jonathan Rubenstein
#881626#75
Date:
2022-01-18 00:22:34 UTC
From:
To:
Pardon me, I need to proofread.

I mean busybox-static.



Best Regards,
Jonathan Rubenstein