Details
- Reviewers
gordon freqlabs cy eugen_grosbein.net rgrimes pstef gnn bz donner - Group Reviewers
network - Commits
- rG4214f6cbb467: ftpd: add deprecation notice
rG0e383bb3cd18: ftpd: add deprecation notice
rGda722491d3cb: ftpd: add deprecation notice
rGcc9347cc79d3: ftpd: add deprecation notice
rG98b98ec1bc7e: ftpd: add deprecation notice
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
I don't personally use the system ftpd myself (used pureftpd for all my previous systems, and no longer running ftp service for a decade now), but I think it is a relatively simple (even compared to pureftpd) application to demonstrate PAM, sendfile, how to write a service daemon, etc.
That's said, I'm neutral with the deprecation but would expect some objections from the community.
I think we should deprecate the client as well. F5 no longer supports the FTP protocol.
Another thought: Deprecate and remove telnet. It's already in contrib and could be very easily moved to ports. (I'll put that on my todo list.)
| libexec/ftpd/ftpd.8 | ||
|---|---|---|
| 49 | This clearly did not happen, but I intend to pursue this for 14.0. | |
I am not from the community of developers and gave some feedback on this on the freebsd-stable@ mailing list. I don't know what you get from depreciating it. If the security is the concern, then it's completely misfired since ftpd is not enabled on default. Comments about deprecating also ftp client I get as an April's fool joke. I don't believe that purging insecure protocol daemons from the base will make the operating system more modern or secure.
On the other hand, so far there was no note about svnlite(1) deprecation and removal, but problems with this, useless now svn, prevented WITH_OPENSSL_KTLS=yes from being the default in FreeBSD 13.0. We have still have useless biff(1) in the tree - so far no notes about deprecations of either one.
+1
I do know a lot of people on the mailing lists have said "please don't deprecate ftpd", but I think we should remove it from base and move it to Ports. FTP isn't as relevant anymore as it was in the pre-web days, or even the 2000s before SFTP took off. Some long-time users may cling to legacy daemons forever doesn't mean we shouldn't deprecate them.
It's easier/better to use HTTP for public downloads and SFTP for authenticated downloads/uploads. FTP over SSL (FTPS) never took off, and FTP is still unencrypted even today, whereas SSL is a must-have for toady's internet. Carrier Grade NAT is very real for many people (virtually all mobile connections and a lot of the developing world) which may break FTP.
Not to mention removing ftpd removes the maintenance burden for developers. Keeping ftpd may save 5 minutes for a few long-time users but could also dissuade newer developers if they have to worry about software nobody uses. After all, Minix is basically abandoned after AST retired: nobody wants to maintain Minix anymore.
But people who still have a use for ftpd could just install the proposed port, so people aren't in limbo if they still depend on it. The ftpd Port could still be "if you want it, you can get it yourself".
Please keep ftp and telnet clients and servers in base system. Removing violates POLA and does not buy anything. Servers already disables by default.
Same here. Removing clients to access other devices, which nobody has a clue about, is a bad decision.
Telnet and FTP are used by various enterprise devices like UPS and phone bridges, which have lifetimes of decades, not years.
Telnet is a handy debugging tool, because you can make an interactive TCP connection to arbitrary ports.
OTOH it might have a life in ports, like tcpdump and other tools.
Rather than spend cycles on deprecating USED features, please spend cycles on getting pkg base done so that those that feel they have no need for things like ftp/ftpd/telnet/telnetd/foo/bar/etc can choose to not have these and those of us who live and die by such tools can choose to have them.
If there are security bugs in ftpd that will force us to release errata. It won't be the vocal users' responsibility to handle it. On the other hand, it wouldn't painful to pkg install ftpd unless you're emotionally attached. The existence of ftpd in base also provokes suggestions to maintain and enhance it (for example with encryption support).
MacOS has also done this.
I don't understand why this should be necessary. In fact *because* MacOS depreciated client && server. I discovered it was trivial to simply copy my already built FreeBSD version over to MacOS and use it there. I found it much nicer than the GNU version. :-) Why remove them? I have used and depend on both for _years_. inetd(8) && hosts.allow(5) provide reasonable enough security. Or are they being removed as well?
To be clear, this isn't a referendum on whether we should deprecate ftpd. We are going to deprecate it. There is no need for ftpd to live in the base system. It hasn't been a core system daemon in at least 10 years, probably closer to 15 years. The fact we had to issue an SA against it recently helps remind us of the cost we bear keeping this in tree.
All of that said, we are not removing the client from base. Additionally, ftpd will still exist in the ports tree and will be able to be trivially installed via the pkg system. Think of this like HTTP(S). We have a client in the base, but we do not ship a server. This will be the same scenario for ftpd.
As for the whataboutism on why we aren't spending energy to get pkgbase out the door: Secteam isn't in a position to get pkgbase out the door but we can reduce the scope of code we have to issue security advisories in the base system.
Gordon
Hat: security-officer
Referendum or not. The mailing lists reaction should be evidence enough that the FreeBSD user base (those for which FreeBSD exists) have a different opinion on this decision.
The fact we had to issue an SA against it recently helps remind us of the cost we bear keeping this in tree.
Then let me kindly point out these other offenders:
sshd
rpcbind
nfsd
ypbind
inetd
These pose a far greater affect on the security of the FreeBSD base system, than ftpd could ever hope to achieve.
Look. I'm NOT trying to be disagreeable here. I know everything comes at a cost. All these daemons that exist within base are _optional_. As they can be included or not via src.conf(5). ftpd(8) aside from perhaps ypbind is probably the least offensive of them. But perhaps one the most useful utilitarian wise. Just seems unfair. Creates more work for me and others that have come to depend upon its existence in base. I'll be more than happy to maintain, and take full responsibility for its existence in base. If that helps.
All of that said, we are not removing the client from base. Additionally, ftpd will still exist in the ports tree and will be able to be trivially installed via the pkg system. Think of this like HTTP(S). We have a client in the base, but we do not ship a server. This will be the same scenario for ftpd.
As for the whataboutism on why we aren't spending energy to get pkgbase out the door: Secteam isn't in a position to get pkgbase out the door but we can reduce the scope of code we have to issue security advisories in the base system.
Gordon
Hat: security-officer
Thank you for all your time, and consideration in this matter.
Chris
Hat: Administrator
Hum, not a core system functionality? May I remind you that ftp://ftp.freebsd.org exists? Though it probably does not run the base system ftpd, it DOES run that functionality. Also so much for the project being a democracy, seems that core@ and security@ now simply dictate to developers@ how things are to be done... nothing personal Gordon, but that is exactly how this is coming across.
We have cgit.f.o and git.f.o, but no git in base.
There is net/gitup and I think that functionally equivalent should exist in base, but I would like to see gitup's code improve before it gets imported, if that happens.
Also so much for the project being a democracy, seems that core@ and security@ now simply dictate to developers@ how things are to be done...
Who should get to decide how things are to be done? The majority of people? The majority of FreeBSD users? The majority of FreeBSD developers? Or maybe the core that was chosen by the majority of developers? Democracy as you describe it effectively means nothing ever changes because there is always someone whose feelings are hurt by a decision made.
Ahem. As you already noted; Democracy is a majority. *Which* majority is something else.
I'd only like to add that democracy is akin to popularity. User popularity keeps FreeBSD alive. Isn't that pole FreeBSD took, what drove the decision to adopt git as the source of future truth for FreeBSD? If ftp(d) is a popular component of base, as the vast majority of mailing list replies would seem to indicate. Maybe it's worth keeping?
Now that this review has devolved to the point of discussing democracy, rather than the deprecation of a piece of long surviving, but, inherently insecure code in our base system, it's time for people to step back from their keyboards and realize that removing this from base does not make it impossible to install or use, it simply reduces the default attack surface of our system. So, let's let emaste put this deprecation in for 14, and move on.
Disagreed. The code is not enabled by default. And it is not insecure. Please do not fix what is not broken.
| libexec/ftpd/ftpd.8 | ||
|---|---|---|
| 56 | Either remove 'the' or add 'port' after? | |
While I understand there is a lot of passion around ftpd, the reality is the world has moved on and ftp is in the dustbin of history. All major web browsers have dropped support for the protocol entirely, over 2 years ago in fact.
And just to re-emphasize, this software exists in the ports/pkg systems and can be trivially installed at any time.