New front-end for OpenSSH SFTP client

Joseph S. Testa
Mon Jun 25 08:48:00 GMT 2001

On Mon, 25 Jun 2001, Robert Collins wrote:

> ----- Original Message -----
> From: "Joseph S. Testa" <>
> To: <>
> Sent: Monday, June 25, 2001 7:41 AM
> Subject: New front-end for OpenSSH SFTP client
> >
> >
> >        I've recently completed Beta 1 of a Windows front-end that I've
> > made for OpenSSH's SFTP client (with cygwin, of course).  Its called
> > 'Shaolin Secure FTP', and is available for free at:
> >
> >
> >
> > Comments and suggestions are welcome.
> >
> >
> >        - Joe Testa
> Comments: (well you asked :] )
> 1) Do you know that under the GPL you need to make available the source
> code for cygwin1.dll when you redistribute it? You are redistributing it
> in your .zip file...

I had this feeling that I forgot something.... and *that's it!*  I'll
repackage Shaolin ASAP.

> 2) It's a bit disappointing that it's written in a proprietary language.
> I don't have the $$$ to buy borland * product (Delphi I presume), so
> having the source really doesn't help me much at all. And yes free
> speech != free beer... all the same something that I can build here -
> say c++ would be much nicer.

Its written in Borland C++ Builder 5.0.  The compiler is free and
available from .

> 3) I' not about to use a product that needs a customised ssh and sftp.
> If you can get your alterations rolled into the unix product fine. (Why
> break the output format anyway ?)

Well, its a little tricky...

The problem is that Shaolin uses CreateProcess() to spawn off the sftp.exe
executable and redirect its standard input and output handles.  Now
sftp.exe spawns ssh.exe itself so that it can handle authentication,
etc...  The problem comes into play because ssh.exe prompts the user for
two things:

	1.)  It waits for the user to type in 'yes' or 'no' -- this is in
reference to whether or not to connect to the host even though the key is
not in the database (keys are *never* in the database because ssh.exe
can't write to the file system if you execute it from
instead of bash.exe.  Therefore, the front-end itself takes care of key

	2.)  It prompts the user for the password.

Now because I can't call CreateProcess() myself to spawn ssh.exe, I don't
know how to redirect its handles.  I'm sure there is a way to do it once
its been loaded (does anyone know?).

I made some minor changes to ssh.exe so that the user wouldn't have to
type 'yes<enter>' into ssh's empty, black console window (it doesn't even
prompt for anything -- it just sits there).  Since this would confuse new
users, and it is unnecessary anyway, I commented out a few lines in
sshconnect.c and recompiled.  [ I don't know if this just made sense or
not =P ]

> Other than that - hey great concept....
> and suggestions
> 1) Put the source in CVS - there are plenty of available
> free-software-supporting CVS repositories available. Chris Faylor has
> even been known to make CVS space available on for
> worthy projects. CVS does several things I consider important: It
> provides a change history; it allows relatively easy concurrent
> development and finally it means the end user can track your progress
> without having to download an entire zip each time.

I was considering this.  Unfortunately, my development machine has no
Internet connection.  I have to transfer things on 1.44M floppy disk
between it and a computer with a 28.8 modem that is three rooms away (I
miss RIT's OC3 line...).

> 2) Also it might be nice for visitors to your site to be told that it's
> under the GPL before downloading the file (not that I object to the GPL
> :] ).
> 3) Use bz2. Mucho smaller on source. (Saved 100k at default on your 1.5
> Mb archive, and given you only had 700kb out of 4.5Mb extracted data
> thatsnot too bad).
> 4) Use C++ or C. Really. Even TCL.

[ see above ]

> 5) If you distribute changes to something (ie ssh) distribute contextual
> diffs, not replacement files. It eases your support burden and makes
> your change more long lasting. (Folk can see what you are changing, not
> just the new file, and thus can still use your code on newer source).

As you already saw, I wasn't thinking when I was packaging the source.
Good idea.

> 6) Don't redistribute cygwin1.dll. It's trivially available from
> via setup.exe, which will also install the correct mount
> table and allows folk to update cygwin1.dll easily. That also frees you
> from needing to distribute the tarball of the cygwin source. Lastly, as
> cygwin won't operate correctly with multiple version skewed copies ona
> single machine, it will reduce user complaints.

I don't think your average AOL user has the patience (or intelligence) to
download cygwin1.dll themselves and put it in the right place on their
filesystem.  And, because I'm sending it to software sites like, et al, the success of this project is dependent upon
it working right out of the box.

> Rob

Thank you very much for your insight.

	- Joe Testa

"Those who desire to give up Freedom
in order to gain Security, will not have,
nor do they deserve, either one."

                       -- Thomas Jefferson

Want to unsubscribe from this list?
Check out:

More information about the Cygwin mailing list