> Dan's anonftpd chroots itself, and there's no way out. Crackers
> simply cannot break authentication because there *is* no
> authentication. Anybody can download only the files in the ftpd
> directory. Anything else is less secure.
But giving Dan's anonftpd the binary label "secure" and anything
different the binary label "insecure" seems misleading to me. Dan's
anonftpd is still subject to stream modification of the file you
request, for instance (not that I particularly expect an ftpd to solve
this problem; it's hard), and your idea of use of "less secure" really
seems to mean "potentially less secure."
> Isn't it about time we had an ftp server which cooperated with a
> visual ftp client by giving it an easily parsed listing format?
If this format is intended for programs and not users, wouldn't it be
better to provide it under a new query? The description of LIST in
RFC 959 says about the information returned:
Since the information on a file may vary widely from system
to system, this information may be hard to use automatically
in a program, but may be quite useful to a human user.
