Live data from Hacker News

FTP is 50 years old

filestash.app

81–90 of 187 posts

Re: FTP is 50 years old

#81
post #51

Earlier quoted context omitted.

These standards are so very different, and they don't scale well. TFTP is actually over UDP, guarantees only one data packet on the wire at any one time (no sliding window), does not support listing a remote directory, and is extreme in simplicity. FTPS has such arbitrary controls for TLS optional versus required status over control and data channels that it is easy to misconfigure. SFTP lacks two key features (amids…

SFTP supports anonymous access. I actually just shut down my sftp server to move it or I would be able to show you, but it's super easy on CentOS. Just set up chroot and set a null pw for the usernames of your choice. You can use posix permissions to hide subdirs or files if you wish. You can use chattr or mount permissions to make it read-only or write-only. The only thing missing is browser support. I might have ti…

Ideally, an FTP emulation of any password for FTP/anonymous, recorded to /var/log/secure, would be within SFTP (maybe checking for an "@" character followed by some dots, hoping for an email).

Forcing the null password up the stack to /etc/shadow (or other credential sources) potentially compromises PAM and other applications that may depend upon it.

It sounds like you've implemented a separate SSH server within a chroot for this to protect the base OS; I've done the same for tinyssh with nspawn for an internal project. This is not easy.

Anonymous access for SFTP doesn't scale to the extent used in FTP, even omitting browser access.

Re: FTP is 50 years old

#82
post #61

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…

Just curious on the motivation. Why not run a regular FTP server and have your application periodically look for new files to process? For horizontal scaling, you just take a distributed lock on the file name.

Because nodejs kubernetes modern cloud.

Re: FTP is 50 years old

#83
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.

...and the US healthcare system.

Re: FTP is 50 years old

#84
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…

I still use it to sync folders to my iPad (from Documents Readdle). Since walled gardens don't leave much options open, it's basically either that or a cloud provider -- and no free cloud plan has enough space to store these folders.

So FTP wins easily this one. It's free with unlimited storage, always has been, always will be.

Re: FTP is 50 years old

#85
post #61

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…

Just curious on the motivation. Why not run a regular FTP server and have your application periodically look for new files to process? For horizontal scaling, you just take a distributed lock on the file name.

That honestly sounds more complicated. FTP isn't that difficult of a protocol, especially if you only need to support one known client, you can take all sort of shortcuts.

If you deploy an existing FTP server, and _then_ integrate with it at the filesystem level you now have two components, and your sysadmin requirements grow. Now you gotta administrate an FTP server that's probably written for classic UNIX single server usage, gotta handle filesystem permissions, gotta somehow hook up your distributed locks to the filesystem, sanitize filenames for your chosen filesystem.

Honestly filesystems suck, there's so many gotchas from a security perspective, when all you really want is to pipe binary data in this side, and out the other side.

I implemented an IRC bot in a few hours in javascript one day. Those classic IETF text based protocols are actually really fun and easy to implement, especially in a language that makes strings safe and easy (i.e. not C).

I could easily see figuring out all the deployment concerns around integrating with an existing FTP server end up taking way longer than just integrating the subset needed for this use case.

Re: FTP is 50 years old

#87
post #36

Earlier quoted context omitted.

ASCII is a very obvious format. If you take the english alphabet and symbols, it fits almost perfectly in the first 7 bits. In 5th grade I tried encoding English in binary, and noticed how I accidentally reinvented ASCII.

I wouldn't say it's obvious. There's some careful decisions in the design that might not be obvious at first sight, such as having upper and lowercase characters be the same save for a single bit.

I see. I would retract my statement if HN let me edit.

Re: FTP is 50 years old

#90
post #61

Earlier quoted context omitted.

Just curious on the motivation. Why not run a regular FTP server and have your application periodically look for new files to process? For horizontal scaling, you just take a distributed lock on the file name.

That honestly sounds more complicated. FTP isn't that difficult of a protocol, especially if you only need to support one known client, you can take all sort of shortcuts. If you deploy an existing FTP server, and _then_ integrate with it at the filesystem level you now have two components, and your sysadmin requirements grow. Now you gotta administrate an FTP server that's probably written for classic UNIX single se…

Active mode is pretty weird. Coordinating a single client across two ports sounds difficult to me, but I've never implemented it. If that's not a difficult protocol, then what is?
Post reply on HN