In message <CAPyFy2AbP2X339zbemZ9Y8edjNKdyygnR9mH48Q78nxwDtOBAg at 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?> > I'm happy to make a port for it if anyone needs it. Comments?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. I think we should make it our goal to remove any and all unencrypted protocols from FreeBSD by 2025. -- Cheers, Cy Schubert <Cy.Schubert at cschubert.com> FreeBSD UNIX: <cy at FreeBSD.org> Web: https://FreeBSD.org NTP: <cy at nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
On Mon, Apr 5, 2021 at 8:45 AM Cy Schubert <Cy.Schubert at cschubert.com> wrote:> In message > <CAPyFy2AbP2X339zbemZ9Y8edjNKdyygnR9mH48Q78nxwDtOBAg at 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://. >Whoa there! You can't remove ftp and http from libfetch, because FreeBSD doesn't control all of the servers that our users need to fetch from. Not even close.> - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS > traffic? > > > > > I'm happy to make a port for it if anyone needs it. Comments? > > 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. >Maybe, but that would be an impediment to adding Capsicum support.> > 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. > > I think we should make it our goal to remove any and all unencrypted > protocols from FreeBSD by 2025. >tftpd is still vitally important for PXE booting. And unencrypted NFS will certainly live on past 2025. -Alan
>> 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)My preference would be to leave those four in the system. However, I can live with removal, as long as they are available as ports.> - remove ftp:// and http:// from libfetch. This is 2021 and we should all > use https://.Please don't. There is still a lot of content not available over https (and quite a few web sites with only "readonly" type content). Removal of ftp:// and http:// from libfetch simply means I'll have to install wget instead - and we're getting ever close to FreeBSD being only a kernel.> - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS > traffic?Because I trust my (European) ISP significantly more than I trust big US companies? Yes, I have a pretty good idea what Cloudflare, Google etc have said about the queries they receive. I still don't see a reason to trust them, given their actions in other areas. Bert Hubert has written much better then I can about moving everything to DoH/DoT: https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/ Steinar Haug, Nethelp consulting, sthaug at nethelp.no
On 05.04.2021 17:44, Cy Schubert wrote:> - remove ftp:// and http:// from libfetch. This is 2021 and we should all > use https://.Please, explain how to setup simple sever which allows upload and on-server file management with https ;-) I know letters "WebDAV", but I don't know any ftp-like client for it. And server is apache24, which is much more huge security target than simple ftpd. Even `sftp` is ugly.> - replace DNS lookups with DoH and/or DoT. Why let your ISP see your DNS > traffic?As soon as FreeBSD will include in *base* system DoH/DoT recursive server (as it includes unbound for simple DNS now). I don't understand why should I trust "centralized" DoH services. Do we want to import libnghttp2 to base for this? -- // Lev Serebryakov
Hi, I'm a bit late to the discussion On Mon, Apr 05, 2021 at 07:44:59AM -0700, Cy Schubert wrote:>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?Very firmly against this, and this sort of thing, for the following reasons: 1. I want an OS, not a kernel. If I just want a kernel, then why not go with linux? FreeBSD is meant to be, I think, (generally), a server OS. So, would you agree that it needs the ability to have server protocols easily configured, with a minimum of fuss, without packages? 2. a lot of infrastructure depends on ftpd. it's easy to configure securely ftpd in base. 3. there are some networks, like internal ones, where encryption is not a requirement, or appropriate. 4. there are some places where encryption is in fact illegal.>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.5. some services commonly don't use https. Lots of internet radio stations don't. If https is enforced then the user will have to jump through more hoops than they already do in order to, in this case, listen to internet radio. Or face a loss of functionality. 6. not everywhere will have constant internet access. Not everyone will want to use pkgs or have space for the ports tree.>I think we should make it our goal to remove any and all unencrypted >protocols from FreeBSD by 2025.I think you should carefully think of the consequences of removing functionality in the default install. It will make it less useful, not more. -- J. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20210407/3aeef1ac/attachment.sig>
On 2021-04-05 07:44, Cy Schubert wrote:> In message <CAPyFy2AbP2X339zbemZ9Y8edjNKdyygnR9mH48Q78nxwDtOBAg at 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