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
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to