Subject: Re: avoiding reinventing the wheel on file transfer.

From: Darren Moffat <[email-masked]>
Date: Tue, 27 Mar 2001 17:25:33 -0800 (PST)

>So, I have this concern that we're going to spend a whole lot of time
>on the file transfer draft, and in the process reinvent a couple
>wheels which have already been built.

>Here's a half-formed suggestion for the working group...
>
>file transfer involves a bunch of really ugly issues (newline
>conventions, binary/ascii/... modes, i18n of filenames, etc., etc.).
>Many of these problems have already been tackled by FTP.

To me it looks like the current filexfer draft is trying to be more
than FTP and is starting to look more and more like an early version
of NFS so I share the concern.

--
Darren J Moffat

---

From: Barney Wolff <[email-masked]>
Date: Tue, 27 Mar 2001 20:34:54 -0500

I see two problems with simply redirecting ports to use the
existing ftpd:

1.  One of the major reasons to run sshd is to be able to shut
down telnetd and ftpd, not only because of cleartext logins
but also because they have been prone to security bugs.  Yes,
one could perhaps arrange for ftpd to listen only on localhost,
but there is still the possibility of privilege escalation via
a buggy ftpd.

2.  The two-connection model for file transfer has not, in retrospect,
worked out well.  (IMHO)

Barney Wolff

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 27 Mar 2001 20:40:06 -0500

> existing ftpd..

Of course, there are problems with that, which is why it wasn't what I
proposed.

I proposed running the ftp *protocol* over a collection of ssh
channels through a single ssh connection.

Most likely an implementation of that could reuse most of an ftp
client/server implementation.

					- Bill

---

From: Jason R Thorpe <[email-masked]>
Date: Tue, 27 Mar 2001 18:21:04 -0800

> but there is still the possibility of privilege escalation via

This seems like an implementation issue.  An implementation could
certainly choose to hack ftpd to run on a channel created by sshd
(rather than one created by inetd).

 > 2.  The two-connection model for file transfer has not, in retrospect,

Passive mode?

-- 
        -- Jason R. Thorpe <[email-masked]>

---

From: Barney Wolff <[email-masked]>
Date: Tue, 27 Mar 2001 21:47:34 -0500

Easy for the initial listen, not so easy for the data conn(s).
But as I've been corrected, the proposal is to reuse the protocol,
not the intact ftpd.

>  > 2.  The two-connection model for file transfer has not, in retrospect,

Still clumsy.  The sync issues on aborting a transfer, for example.
Third-party transfers.

The historical motivations for using a separate data channel no
longer apply.  Again, imho.

But I surely do believe in KISS.  Bells and whistles, if any, belong
in shareware clients.

Barney Wolff