Deprecating base system ftpd?

[Chris]

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