On 3 Apr 2021, at 22:21, Eugene Grosbein <eugen at grosbein.net> wrote:> > 04.04.2021 3:39, Ed Maste wrote: > >> 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'm happy to make a port for it if anyone needs it. Comments? > > I'm strongly against remove of stock ftpd. FTP is fastest protocol for both testing > and daily file transfer for trusted isolated segments, and even for WAN wrapped in IPSec. > > Our stock ftpd has very short backlog of security issues comparing with other FTP server implementations, > mostly linked with libc or other libraries and not with ftpd code itself. > > Please don't fix what ain't broken. Please.How would you draw the line between something that must be part of the base system vs. something that would be better off as part of the ports tree? What bar should ftpd have to meet to warrant remaining in base vs moving to ports? Personally, I?ve never enabled it nor had any desire to. FTP is, at this point in time, thoroughly obsolescent, and I cannot imagine that it is something that most people enable, if they are even aware of its existence. Why can?t it simply be installed from the ports for the occasional user who still requires it? Why should the base system contain obsolete stuff that few people will use? Surely the ports tree serves this need better? Can I ask, for those who do enable it, why isn?t ?sftp? acceptable (or ?scp?)? Both provide a similar function, securely, which also works with a basic installation without any ports. SSHFXP, the protocol underlying sftp is better specified, less ambiguous and more fault tolerant and safe than the FTP protocol ever was. The client is better than most ftp clients, and the server (/usr/libexec/sftp-server) is started on demand on a per-connection basis. What makes FTP more desirable than a service over SSH which is (from a technical and usability point of view) a better FTP than FTP ever was? Kind regards, Roger
I'd shed no tears losing ftp+(d). That noted, tftp (the daemon) is still used to load firmware on too many devices (changing) and telnet (the client) can be useful in debugging network listeners and chatting with stupid IOTs that can't be bothered with using SSH. I haven't enabled either telnetd or ftpd daemon in at least a decade. My baseline would be, " is this something I'd want working from a live iso?". Maybe the better (and tougher) decision is, "what belongs in a modern integrated OS environment?". I leave that to better minds than mine. jim -----Original Message----- From: owner-freebsd-stable at freebsd.org <owner-freebsd-stable at freebsd.org> On Behalf Of Roger Leigh Sent: Monday, April 5, 2021 11:27 AM To: freebsd-stable stable <freebsd-stable at freebsd.org> Subject: Re: Deprecating base system ftpd? On 3 Apr 2021, at 22:21, Eugene Grosbein <eugen at grosbein.net> wrote:> > 04.04.2021 3:39, Ed Maste wrote: > >> 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'm happy to make a port for it if anyone needs it. Comments? > > I'm strongly against remove of stock ftpd. FTP is fastest protocol for > both testing and daily file transfer for trusted isolated segments, and even for WAN wrapped in IPSec. > > Our stock ftpd has very short backlog of security issues comparing > with other FTP server implementations, mostly linked with libc or other libraries and not with ftpd code itself. > > Please don't fix what ain't broken. Please.How would you draw the line between something that must be part of the base system vs. something that would be better off as part of the ports tree? What bar should ftpd have to meet to warrant remaining in base vs moving to ports? Personally, I?ve never enabled it nor had any desire to. FTP is, at this point in time, thoroughly obsolescent, and I cannot imagine that it is something that most people enable, if they are even aware of its existence. Why can?t it simply be installed from the ports for the occasional user who still requires it? Why should the base system contain obsolete stuff that few people will use? Surely the ports tree serves this need better? Can I ask, for those who do enable it, why isn?t ?sftp? acceptable (or ?scp?)? Both provide a similar function, securely, which also works with a basic installation without any ports. SSHFXP, the protocol underlying sftp is better specified, less ambiguous and more fault tolerant and safe than the FTP protocol ever was. The client is better than most ftp clients, and the server (/usr/libexec/sftp-server) is started on demand on a per-connection basis. What makes FTP more desirable than a service over SSH which is (from a technical and usability point of view) a better FTP than FTP ever was? Kind regards, Roger _______________________________________________ freebsd-stable at freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
On 4/5/21 8:27 PM, Roger Leigh wrote:> Can I ask, for those who do enable it, why isn?t ?sftp? acceptable (or ?scp?)?Because it's an *incompatible* replacement. While I never enabled ftpd, I was once asked to. I refused and enabled sftp instead: the problem was that for 99% of the customers on the other side of the wire, this wasn't the same thing. It was hard to make them change their habits, their clients, etc... That said, I vote for moving ftpd to ports. Just my 2c.
"Can I ask, for those who do enable it, why isn?t ?sftp? acceptable (or ?scp?)? Both provide a similar function, securely, which also works with a basic installation without any ports. SSHFXP, the protocol underlying sftp is better specified, less ambiguous and more fault tolerant and safe than the FTP protocol ever was. The client is better than most ftp clients, and the server (/usr/libexec/sftp-server) is started on demand on a per-connection basis. What makes FTP more desirable than a service over SSH which is (from a technical and usability point of view) a better"r FTP than FTP ever was?" Because we have a lot of legacy clients, in the field that use ftp to transfer non sensitive data, it's simple, and I don't see the need to revisit this because it's an old fashioned non encrypted protocol, you may disagree that's fine, but for many purposes it does the job. Sure there may be better tools, but I see no reason to re issue lots of client apps that are built on this and are working fine needlessly, G On Mon, Apr 5, 2021 at 7:28 PM Roger Leigh <rleigh at codelibre.net> wrote:> On 3 Apr 2021, at 22:21, Eugene Grosbein <eugen at grosbein.net> wrote: > > > > 04.04.2021 3:39, Ed Maste wrote: > > > >> 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'm happy to make a port for it if anyone needs it. Comments? > > > > I'm strongly against remove of stock ftpd. FTP is fastest protocol for > both testing > > and daily file transfer for trusted isolated segments, and even for WAN > wrapped in IPSec. > > > > Our stock ftpd has very short backlog of security issues comparing with > other FTP server implementations, > > mostly linked with libc or other libraries and not with ftpd code itself. > > > > Please don't fix what ain't broken. Please. > > How would you draw the line between something that must be part of the > base system vs. something that would be better off as part of the ports > tree? What bar should ftpd have to meet to warrant remaining in base vs > moving to ports? > > Personally, I?ve never enabled it nor had any desire to. FTP is, at this > point in time, thoroughly obsolescent, and I cannot imagine that it is > something that most people enable, if they are even aware of its > existence. Why can?t it simply be installed from the ports for the > occasional user who still requires it? Why should the base system contain > obsolete stuff that few people will use? Surely the ports tree serves this > need better? > > Can I ask, for those who do enable it, why isn?t ?sftp? acceptable (or > ?scp?)? Both provide a similar function, securely, which also works with a > basic installation without any ports. SSHFXP, the protocol underlying sftp > is better specified, less ambiguous and more fault tolerant and safe than > the FTP protocol ever was. The client is better than most ftp clients, and > the server (/usr/libexec/sftp-server) is started on demand on a > per-connection basis. What makes FTP more desirable than a service over > SSH which is (from a technical and usability point of view) a better FTP > than FTP ever was? > > Kind regards, > Roger > > _______________________________________________ > freebsd-stable at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >
06.04.2021 1:27, Roger Leigh wrote:>>> 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'm happy to make a port for it if anyone needs it. Comments? >> >> I'm strongly against remove of stock ftpd. FTP is fastest protocol for both testing >> and daily file transfer for trusted isolated segments, and even for WAN wrapped in IPSec. >> >> Our stock ftpd has very short backlog of security issues comparing with other FTP server implementations, >> mostly linked with libc or other libraries and not with ftpd code itself. >> >> Please don't fix what ain't broken. Please. > > How would you draw the line between something that must be part of the base system vs. something > that would be better off as part of the ports tree? What bar should ftpd have to meet to warrant remaining in base vs moving to ports?POLA at least.> Personally, I?ve never enabled it nor had any desire to. FTP is, at this point in time, thoroughly obsolescent,Because someone told us so?> and I cannot imagine that it is something that most people enable, if they are even aware of its existence. > Why can?t it simply be installed from the ports for the occasional user who still requires it?This is one of services that should be available even if distfiles/packages are not reachable. You know, sshd used to be in ports too.> Can I ask, for those who do enable it, why isn?t ?sftp? acceptable (or ?scp?)?sftp is not compatible with FTP clients and FTP is faster, basically it is plain TCP socket for data transfer.
On 2021-04-05 11:27, Roger Leigh wrote:> On 3 Apr 2021, at 22:21, Eugene Grosbein <eugen at grosbein.net> wrote: >> >> 04.04.2021 3:39, Ed Maste wrote: >> >>> 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'm happy to make a port for it if anyone needs it. Comments? >> >> I'm strongly against remove of stock ftpd. FTP is fastest protocol for both >> testing >> and daily file transfer for trusted isolated segments, and even for WAN >> wrapped in IPSec. >> >> Our stock ftpd has very short backlog of security issues comparing with >> other FTP server implementations, >> mostly linked with libc or other libraries and not with ftpd code itself. >> >> Please don't fix what ain't broken. Please. > > How would you draw the line between something that must be part of the base > system > vs. something that would be better off as part of the ports tree? What bar > should > ftpd have to meet to warrant remaining in base vs moving to ports? > > Personally, I?ve never enabled it nor had any desire to. FTP is, at this > point in > time, thoroughly obsolescent, and I cannot imagine that it is something that > most > people enable, if they are even aware of its existence. Why can?t it simply > be > installed from the ports for the occasional user who still requires it? Why > should the base system contain obsolete stuff that few people will use? > Surely > the ports tree serves this need better? > > Can I ask, for those who do enable it, why isn?t ?sftp? acceptable (or > ?scp?)?Sure. Because it's part of a one-time task. It might be part of a server setup. Or might a task that must be done on thousands of machines. It needs to be available out-of-the-box, and needs no overhead for setup (key exchange, config, etc...). This scenario may also be on machines w/o any external sources/packages. IOW everything should be available out of the box, with little to no additional setup overhead. ftp(1), and ftpd(8) provide everything required at no additional cost. :-)> Both provide a similar function, securely, which also works with a basic > installation without any ports. SSHFXP, the protocol underlying sftp is > better > specified, less ambiguous and more fault tolerant and safe than the FTP > protocol > ever was. The client is better than most ftp clients, and the server > (/usr/libexec/sftp-server) is started on demand on a per-connection basis. > What > makes FTP more desirable than a service over SSH which is (from a technical > and > usability point of view) a better FTP than FTP ever was? > > Kind regards, > Roger >--Chris