[tahoe-lafs-trac-stream] [tahoe-lafs] #2097: deprecate FTP in favor of SFTP?
tahoe-lafs
trac at tahoe-lafs.org
Sun Nov 3 19:00:10 UTC 2013
#2097: deprecate FTP in favor of SFTP?
-------------------------+-------------------------------------------------
Reporter: zooko | Owner: daira
Type: defect | Status: new
Priority: normal | Milestone: 1.11.0
Component: unknown | Version: 1.10.0
Resolution: | Keywords: ftpd sftp forward-compatibility
Launchpad Bug: | brians-opinion-needed
-------------------------+-------------------------------------------------
Description changed by zooko:
Old description:
> There are major limitations to the LAFS-FTPd implementation—starting with
> the fact that mutable files just don't work—and there is no intent to fix
> these limitations, because the Tahoe-LAFS developers think that the SFTP
> protocol is better, the LAFS-SFTP implementation already works better,
> and we think everyone should switch from FTP to SFTP. There are more
> details about this here, in addition to the obvious issue that FTP lacks
> confidentiality and integrity: [source:trunk/docs/frontends/FTP-and-
> SFTP.rst] .
>
> However, I've observed that people continue to use FTP because:
> * They think that the only difference between the two is that SFTP is
> encrypted, and
> * They are accessing it over localhost only, anyway, or they otherwise
> aren't worried about attackers snooping on or altering their files in
> flight, and
> * Setting up LAFS-SFTPd requires an extra step more than setting up LAFS-
> FTPd — you have to create an ssh keypair.
>
> In other words, I've observed that people are unaware of the limitations
> and problems in the FTP protocol and the LAFS-FTPd implementation,
> mentioned above and documented in [source:trunk/docs/frontends/FTP-and-
> SFTP.rst], even though we've documented them from the beginning. This is
> a lesson we've learned many times: it doesn't matter what the
> documentation says, people will continue to use a feature as long as it
> *appears* to work.
>
> The most recent example of this pattern is the choice of Stig Atle
> Steffensen to use LAFS-FTPd even though I already told him that there
> were relevant limitations notes in the FTP-and-SFTP.rst document.
> Apparently he didn't read it, didn't notice the limitations part, or
> thinks those limitations are irrelevant to his use case. (Which I guess
> could be true for him, if he uses only ASCII filenames, only immutable
> files, doesn't have servers-of-happiness failures on his grid, etc.) In
> this tweet he wrote, it sounded like he wasn't aware of those other
> issues and thought that the only difference between FTP and SFTP was
> encryption:
>
> “ftp is unencrypted, sftp is encrypted, but if you run everything on
> 'localhost' then it does not matter if you use one over the other”
>
> — https://twitter.com/stigatle/status/397059080499789824
>
> This ticket proposes to deprecate and then remove the LAFS-FTPd
> implementation in favor of LAFS-SFTPd. The justification is that LAFS-
> FTPd lacks important functionality, like mutable files, error reporting,
> and non-ASCII filenames, not to mention confidentiality and integrity,
> and we have no plans to add it, because the FTP protocol can't support
> some of those features, and because we've already implemented all of that
> in LAFS-SFTPd and we think anyone who uses LAFS-FTPd could (with only a
> *little* added effort) switch to LAFS-SFTPd.
>
> I'm marking this with the tag {{{forward-compatibility}}} and putting it
> into Milestone 1.11 because if we want to leave the deprecated LAFS-FTPd
> functionality in place for a full major release, then ''not'' doing the
> deprecation notice in 1.11 will obligate us to keep LAFS-FTPd
> functionality running in 1.12.
New description:
There are major limitations to the LAFS-FTPd implementation—starting with
the fact that mutable files just don't work—and there is no intent to fix
these limitations, because the Tahoe-LAFS developers think that the SFTP
protocol is better, the LAFS-SFTP implementation already works better, and
we think everyone should switch from FTP to SFTP. There are more details
about this here, in addition to the obvious issue that FTP lacks
confidentiality and integrity: [source:trunk/docs/frontends/FTP-and-
SFTP.rst] .
However, I've observed that people continue to use FTP because:
* They think that the only difference between the two is that SFTP is
encrypted, and
* They are accessing it over localhost only, anyway, or they otherwise
aren't worried about attackers snooping on or altering their files in
flight, and
* Setting up LAFS-SFTPd requires an extra step more than setting up LAFS-
FTPd — you have to create an ssh keypair.
In other words, I've observed that people are unaware of the limitations
and problems in the FTP protocol and the LAFS-FTPd implementation,
mentioned above and documented in [source:trunk/docs/frontends/FTP-and-
SFTP.rst], even though we've documented them from the beginning. This is a
lesson we've learned many times: it doesn't matter what the documentation
says, people will continue to use a feature as long as it *appears* to
work.
The most recent example of this pattern is the choice of Stig Atle
Steffensen to use LAFS-FTPd even though I already told him that there were
relevant limitations documented in FTP-and-SFTP.rst. Apparently he didn't
read it, didn't notice the limitations part, or thinks those limitations
are irrelevant to his use case. (Which I guess could be true for him, if
he uses only ASCII filenames, only immutable files, doesn't have servers-
of-happiness failures on his grid, etc.) In this tweet he wrote, it
sounded like he wasn't aware of those other issues and thought that the
only difference between FTP and SFTP was encryption:
“ftp is unencrypted, sftp is encrypted, but if you run everything on
'localhost' then it does not matter if you use one over the other”
— https://twitter.com/stigatle/status/397059080499789824
This ticket proposes to deprecate and then remove the LAFS-FTPd
implementation in favor of LAFS-SFTPd. The justification is that LAFS-FTPd
lacks important functionality, like mutable files, error reporting, and
non-ASCII filenames, not to mention confidentiality and integrity, and we
have no plans to add it, because the FTP protocol can't support some of
those features, and because we've already implemented all of that in LAFS-
SFTPd and we think anyone who uses LAFS-FTPd could (with only a *little*
added effort) switch to LAFS-SFTPd.
I'm marking this with the tag {{{forward-compatibility}}} and putting it
into Milestone 1.11 because if we want to leave the deprecated LAFS-FTPd
functionality in place for a full major release, then ''not'' doing the
deprecation notice in 1.11 will obligate us to keep LAFS-FTPd
functionality running in 1.12.
--
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2097#comment:3>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list