Live data from Hacker News

FTP Must Die

mywiki.wooledge.org

91–100 of 119 posts

Re: FTP Must Die

#91
post #35

Earlier quoted context omitted.

That's actually the standard European order. Testing the Russian locale might be a scary proposition, but certainly not for this specific reason.

It's not just the standard European order, it's the standard order for nearly everywhere on the planet except: > MDY: Belize, USA, parts of Canada, Philippines, Saudi Arabia > YMD: Japan, China, Iran, small bits of Europe > DMY: Probably 3/4 of the planet's land surface That said, YMD should make the most sense (and is most consistent with the universally accepted HMS time format). I try to use YMD wherever I can.

In my country YMD and DMY are used, and I don't see, which is more prevalent. And some people use "." some use "/" and some use "-" as separators. It doesn't seem to cause any problems. You just need to validate inputs (best - show example as the default value), and know which foramt you use.

But MDY is just ugly and should die. It's almost as strange, as German way of saying 123. One hundert, three, and twenty :) Who invented this.

EDIT: didn't wanted to insult Germans :)

Re: FTP Must Die

#92
Awww didums if the OP can't understand and use a simple protocol like FTP good job he never had to work with grown up OSI standards - maybe they should stick to working at mc Donalds.

And those mentioning rsync its not used for the same use cases as ftp.

ftp is usefull for quickly transfereing a few files between systems - rsysnc is used for totaly diferent

Re: FTP Must Die

#93
post #12

Earlier quoted context omitted.

PASV mode came with its own security drama, and doesn't address the core issue with the (absolutely pointless) multiple-connection model of FTP. And so, yes, firewalls and NATs "interact" with FTP --- because they all had to be hacked specifically to deal with the FTP protocol, which moots your rebuttal --- but in doing so they create additional security issues, like the NAT pinning stuff Samy Kamkar posted last year…

Have used tftp for net booting, those legacy bioses cant do anything else, as it really is trivial...

Indeed. TFTP serves its purpose pretty well. FTP doesn't.

Re: FTP Must Die

#94

I think SFTP is an excellent alternative to FTP (as well as FTP over SSL/TLS). It's a whole lot safer than FTP and it solves the archaic annoyance of data ports. Sadly the OpenSSH solution is over the top awkward when it comes to setting up chrooted access, but it works. Introducing something entirely new at this point makes no sense - the situation isn't really as serious as some people want to make it out to be.

Maybe you missed the OpenSSH 4.9 release? http://www.openssh.com/txt/release-4.9 Since then, it is easy to setup a chroot'ed account which easily acts like an ftp server. Have a look at ChrootDirectory and the internal-sftp subsystem.

No, in fact I update every 6 months ever since I started using OpenBSD back in 1999. The problem isn't setting up OpenSSH to offer chrooted sftp access. My gripe is that the sftp subsystem for no solid reason requires that a user directory is root-owned in order to chroot even when the user account experiences a forced sftp response (that is, denying shell access, making it an sftp-only account).

Re: FTP Must Die

#95

Earlier quoted context omitted.

FTP is as obsolete as telnet and has no place being alive today. SSH and SCP provide a much more secure alternative. SFTP is a hack that suffers from all the same problems.

FTP is platform agnostic. As uncool as it may be it's the only realistic choice for companies to share sensitive data.

Please, name me one platform in common use that doesn't have an implementation of ssh/scp.

Re: FTP Must Die

#96

Who still uses FTP? I believe SFTP has been the standard for quite some time already.

The only thing I use FTP for these days is downloading free operating systems like OpenBSD and Arch Linux. For this kind of thing, I think FTP is fine.

Re: FTP Must Die

#97
post #42

Earlier quoted context omitted.

Have used tftp for net booting, those legacy bioses cant do anything else, as it really is trivial...

Has there been a piece of equipment shipped in the last 10 years that legitimately couldn't get a TCP running to bootstrap itself? That's why TFTP exists: to avoid the need for TCP.

[deleted]

Re: FTP Must Die

#98
post #10
post #5

Time and time again I resort to FTP to transfer files between computers that won't talk to each other via system-provided file systems. Mac Windows file sharing is so unreliable that I don't even try to use the system any more and just go straight to FTP. But yeah I hate the protocol itself.

Have you tried using SCP? I don't know if Windows comes with a client but a quick search turned up a few options. It is my goto method for transferring files these days but I admittedly don't use Windows.

filezilla supports SFTP, as do most modern windows ftp clients. filezilla even supports pagent as an ssh agent, allowing secure passwordless login.

Any openssh server that supports scp will support sftp unless it has been explicitly disabled.

Re: FTP Must Die

#99

Earlier quoted context omitted.

Maybe you missed the OpenSSH 4.9 release? http://www.openssh.com/txt/release-4.9 Since then, it is easy to setup a chroot'ed account which easily acts like an ftp server. Have a look at ChrootDirectory and the internal-sftp subsystem.

No, in fact I update every 6 months ever since I started using OpenBSD back in 1999. The problem isn't setting up OpenSSH to offer chrooted sftp access. My gripe is that the sftp subsystem for no solid reason requires that a user directory is root-owned in order to chroot even when the user account experiences a forced sftp response (that is, denying shell access, making it an sftp-only account).

the reason the directory must be root owned, is that the chroot directive is also used for normal ssh sessions, where a user owned chroot directory can mean that a user can break out.

Re: FTP Must Die

#100
post #42

Earlier quoted context omitted.

Have used tftp for net booting, those legacy bioses cant do anything else, as it really is trivial...

Has there been a piece of equipment shipped in the last 10 years that legitimately couldn't get a TCP running to bootstrap itself? That's why TFTP exists: to avoid the need for TCP.

Only tftp is widely supported by embedded ROMs, for netboot or for loading a new firmware for embedded devices with broken OS images.

It's not a matter of getting TCP running. You'd need a basic http transfer client, too. Not many network bootloaders or firmware loaders support anything other than tftp.

iPXE supports http. Get iPXE into embedded bootloaders for new firmware loading, and into network device ROMs for network booting, and then people can switch. Until then, it's tftp because that's what everyone supports.

Post reply on HN