Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Apr 2021 10:06:33 -0700
From:      Chris <bsd-lists@bsdforge.com>
To:        freebsd-stable@freebsd.org
Subject:   Re: Deprecating base system ftpd?
Message-ID:  <72489149a8e137fac90c88e4a45c5b09@bsdforge.com>
In-Reply-To: <202104051444.135EixF6025306@slippy.cwsent.com>
References:  <CAPyFy2AbP2X339zbemZ9Y8edjNKdyygnR9mH48Q78nxwDtOBAg@mail.gmail.com> <202104051444.135EixF6025306@slippy.cwsent.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-04-05 07:44, Cy Schubert wrote:
> In message <CAPyFy2AbP2X339zbemZ9Y8edjNKdyygnR9mH48Q78nxwDtOBAg@mail.gmail.c
> om>
> , Ed Maste writes:
>> I propose deprecating the ftpd currently included in the base system
>> before FreeBSD 14, and opened review D26447
>> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
>> I had originally planned to try to do this before 13.0, but it dropped
>> off my list. FTP is not nearly as relevant now as it once was, and it
>> had a security vulnerability that secteam had to address.
> 
> I think this is an excellent start. My shopping list includes:
> 
> - remove ftp(1)
> - remove ftpd(8)
> - remove telnet(1)
> - remove telnetd(8)
> - remove ftp:// and http:// from libfetch. This is 2021 and we should all
> use https://.
> - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS
> traffic?
You've clearly never worked on extremely large networks. Or at least not
considered them in this statement -- think LAN/intranet in large corporate
settings. ftp(1) as well as ftpd(8) are lightweight, and utilitarian. It's
because of this that gives them such great value. They require nothing to
use. They just work with no setup required. With very little setup you can
manage something a little more sophisticated. I can easily script ftp for
complex situations needing nothing more than sh(1) and ftp(1), and it's all
available right-out-of-the-box. This isn't true of the others.
In an internet public facing scenario. It's enough to utilize one specific
line in inetd(8) and 2 in hosts.allow(2). This simplicity and lack of
overhead is not available with the other options.

Because something is old and un-featured does not make it valueless.

> 
>> 
>> I'm happy to make a port for it if anyone needs it. Comments?
A port would be a nice option. But it should remain an option; as in
one _should_ be allowed to get ftp || ftpd out of the box if they so
choose.

> 
> I've started working on splitting ftp and ftpd into an external git repo.
> The problem I've encountered is that though only ftp and ftpd are left the
> resultant repo is still 1.2 GB. If my last attempt fails, there is a choice
> between a 1.2 GB repo and burning ftp forever then the choice is clear:
> burn it forever.
> 
> Adding the following as an option:
> 
> Also note that the tnftp ports are the NetBSD ftp and ftpd. The FreeBSD ftp
> and ftpd are simply copies of tnftp and tnfpd. Would it make more sense to
> share our customizations with NetBSD and we simply reply on NetBSD for the
> client and server in our ports? This last option might be simpler than
> creating a port.
> 
> Personally, I'd suggest we remove the ftpd server *AND* ftp client and rely
> on ports. Having worked on UNIX, Internet security, and firewalls over the
> last 3/5 of my almost 50 year career, I have lamented the existence of the
> FTP protocol back in 1995 and I hate the FTP protocol with greater a
> passion today. Let's simply remove all vestiges of FTP from the base
> system, including libfetch, sooner than later. We don't need it now that we
> have HTTPS and POST; and sftp.
This assumes your willing to expend all the time and overhead to setup a web
server for a simple but absolutely mandatory one time task. When none of the
boxes you're working on are slated for or perhaps are even capable of running
as much. I (or anyone) should be able to have a FULLY functional system 
WITHOUT
the need to get additional sources to build additional functionality -- this
ain't Linux.

> 
> I think we should make it our goal to remove any and all unencrypted
> protocols from FreeBSD by 2025.
Not everyone works exclusively "in the wild". Many also work within safe
environments, where such things, while nice, are unnecessary.

--Chris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72489149a8e137fac90c88e4a45c5b09>