Live data from Hacker News

FTP is 50 years old

filestash.app

151–160 of 187 posts

Re: FTP is 50 years old

#151

Earlier quoted context omitted.

How much better have we gotten at specifying protocols? Have we learned how to make protocols less ambiguous and less susceptible to crazy edge cases which make it burdensome to implement support in practice once there are lots of sloppy implementations in the field?

1. in many cases the misbehaving clients and servers are obviously wrong, but Postel's law means they "worked for me" when the developer tested it 10 years ago before abandoning it. 2. The FTP protocol got a lot of cruft added to it that modern clients don't implement (e.g. any transfer mode other than stream). 3. FTP over TCP predates NATs and firewalls, which caused a lot of problems as well. 4. FTP was designed fo…

Thanks, wonderful reply!

I see that there's been a debate over the applying Postel's Law, a.k.a. the Robustness Principle, for some time:

https://en.wikipedia.org/wiki/Robustness_principle#Criticism

> a defective implementation that sends non-conforming messages might be used only with implementations that tolerate those deviations from the specification until, possibly several years later, it is connected with a less tolerant application that rejects its messages.

That Wikipedia page led me on to this IETF draft from 2019 on protocol maintenance

https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...

> Abstract

> The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time. For a protocol that is actively maintained, the robustness principle can, and should, be avoided.

It seems that you need both for the protocol to be unambiguously, fully specified, and for popular implementations to avoid applying Postel's Law! But we've seen how market forces conspire to work against that.

Brainstorming opportunities for improvement beyond the suggestions in the IETF doc:

• Accompany the protocol with a validation test suite.

• Provide a validation service.

• Treat non-validating messages skeptically ("quirks mode").

Re: FTP is 50 years old

#152
post #127

Amazing. I never thought I would say this, but I actually implemented an FTP server in 2020. This was needed to support firmware updates to specific hardware (Electric Vehicle charging stations). Apparently embedded software developers choose FTP whenever a spec doesn't specify how binary file transfers should work. It was kind of amusing getting FTP to work in a modern cloud environment. I run a single Kubernetes po…

The good old days ... Username: anonymous Anonymous login accepted, enter e-mail address as password. Password: aoeu@aoeu.com I bet aoeu.com and asdf.com got a good amount of unwanted mail back then.

I get ASDF, but what is AOEU based on?

Re: FTP is 50 years old

#154
post #118

Earlier quoted context omitted.

FTP is certainly more flexible and virtual users are far more secure than adding folks to /etc/passwd. PureFTPd [1] was my favorite for that very reason. There have been a few FTP daemons that supported the SFTP protocol and had virtual users, but they had too many bugs for me. I believe ProFTPd was one of them. Regarding SFTP and null passwords, I do not use a separate sshd. I just use the "Match" stanza in OpenSSH.…

I was forced to implement chroot() for SFTP users under Oracle/RedHat Linux 5. We are, alas, still running it. The OpenSSH 4.3 release on this platform does not support the "match" keyword, but I was able to coerce it to run a separate SFTP-only on port 24, where I constrained the SFTP-specific accounts. I find that I prefer this approach. My wily users then discovered that the working passwd entry also let them logi…

It uses pam so you can configure it however you want or even write your own module.

It’s dangerous though, be sure to check these users don’t get shell access or the ability to create network pipes.

Re: FTP is 50 years old

#155

Earlier quoted context omitted.

> I never thought I would say this, but I actually implemented an FTP server in 2020. If you did this for work, junior engineer move in my opinion. This practice is called not invented here syndrome.

This very much depends on the ecosystem they had in their specific embedded environment. Some have a few kilobytes of working memory: so they'd have to download the file and write it straight to flash (yes, security is a problem but manageable). There are many common cases where, for instance, malloc is disabled. You don't always have off-the-shelf packages for every conceivable environment you work in.

It’s a 50 years old protocol, chances are you’re not the first one who has this problem.

Re: FTP is 50 years old

#157
post #73

Not that I think we should go back, but I do miss the wildwest days of web development when it was still acceptable to FTP untested code straight to production. For my first dev job we would develop on production using an FTP client to push up changes on save. One day I was writing an SQL UPDATE statement and I forgot to include a WHERE clause. I basically nuked the entire product DB and it took days to recover becau…

Don’t worry, SFTP is the backbone of the US financial system.

That’s a lot more modern than the expected csv over smtp solutions.

Re: FTP is 50 years old

#158
post #152
post #127

Earlier quoted context omitted.

The good old days ... Username: anonymous Anonymous login accepted, enter e-mail address as password. Password: aoeu@aoeu.com I bet aoeu.com and asdf.com got a good amount of unwanted mail back then.

I get ASDF, but what is AOEU based on?

Dvorak

Re: FTP is 50 years old

#160

On the other side upcoming Firefox 90 is removing support for FTP: https://blog.mozilla.org/addons/2021/04/15/built-in-ftp-impl...

This could just be auto tested as the code would rarely change. It's like Firefox devel has a dartboard of unique and useful features to be randomly removed.
Post reply on HN