1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-04-11 08:08:06 -05:00
Simon Tatham a081dd0a4c Add an SFTP server to the SSH server code.
Unlike the traditional Unix SSH server organisation, the SFTP server
is built into the same process as all the rest of the code. sesschan.c
spots a subsystem request for "sftp", and responds to it by
instantiating an SftpServer object and swapping out its own vtable for
one that talks to it.

(I rather like the idea of an object swapping its own vtable for a
different one in the middle of its lifetime! This is one of those
tricks that would be absurdly hard to implement in a 'proper' OO
language, but when you're doing vtables by hand in C, it's no more
difficult than any other piece of ordinary pointer manipulation. As
long as the methods in both vtables expect the same physical structure
layout, it doesn't cause a problem.)

The SftpServer object doesn't deal directly with SFTP packet formats;
it implements the SFTP server logic in a more abstract way, by having
a vtable method for each SFTP request type with an appropriate
parameter list. It sends its replies by calling methods in another
vtable called SftpReplyBuilder, which in the normal case will write an
SFTP reply packet to send back to the client. So SftpServer can focus
more or less completely on the details of a particular filesystem API
- and hence, the implementation I've got lives in the unix source
directory, and works directly with file descriptors and struct stat
and the like.

(One purpose of this abstraction layer is that I may well want to
write a second dummy implementation, for test-suite purposes, with
completely controllable behaviour, and now I have a handy place to
plug it in in place of the live filesystem.)

In between sesschan's parsing of the byte stream into SFTP packets and
the SftpServer object, there's a layer in the new file sftpserver.c
which does the actual packet decoding and encoding: each request
packet is passed to that, which pulls the fields out of the request
packet and calls the appropriate method of SftpServer. It also
provides the default SftpReplyBuilder which makes the output packet.

I've moved some code out of the previous SFTP client implementation -
basic packet construction code, and in particular the BinarySink/
BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c,
so that the two directions can share as much as possible.
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-09-19 23:08:07 +01:00
2018-10-21 10:02:10 +01:00
2018-10-06 07:28:51 +01:00
2018-10-21 10:02:10 +01:00
2018-09-19 23:08:07 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2012-09-18 21:42:48 +00:00
2018-10-06 07:28:51 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-10-10 21:50:50 +01:00
2018-10-06 07:28:51 +01:00
2017-02-11 00:44:00 +00:00
2018-10-21 10:02:10 +01:00
2017-09-13 19:26:28 +01:00
1999-01-08 13:02:13 +00:00
2018-09-19 23:08:07 +01:00
2018-08-25 14:38:47 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-10-21 10:02:10 +01:00
2018-10-06 07:28:51 +01:00
2018-10-06 07:28:51 +01:00
2018-10-06 07:28:51 +01:00
2018-09-19 23:08:07 +01:00
2018-10-21 10:02:10 +01:00
2018-10-06 07:28:51 +01:00
2018-10-06 07:28:51 +01:00
2018-10-06 07:28:51 +01:00
2018-10-06 07:28:51 +01:00
2018-09-19 23:08:07 +01:00
2018-10-06 07:28:51 +01:00
2018-10-21 10:02:10 +01:00
2018-10-06 07:28:51 +01:00
2018-10-06 07:28:51 +01:00
2018-10-06 07:28:51 +01:00
2018-10-21 10:02:10 +01:00
2018-10-06 07:28:51 +01:00
2018-10-10 21:50:50 +01:00
2018-09-19 23:08:28 +01:00
2018-09-19 23:08:28 +01:00

This is the README for the source archive of PuTTY, a free Windows
and Unix Telnet and SSH client.

If you want to rebuild PuTTY from source, we provide a variety of
Makefiles and equivalents. (If you have fetched the source from
Git, you'll have to generate the Makefiles yourself -- see
below.)

There are various compile-time directives that you can use to
disable or modify certain features; it may be necessary to do this
in some environments. They are documented in `Recipe', and in
comments in many of the generated Makefiles.

For building on Windows:

 - windows/Makefile.vc is for command-line builds on MS Visual C++
   systems. Change into the `windows' subdirectory and type `nmake
   -f Makefile.vc' to build all the PuTTY binaries.

   As of 2017, we successfully compile PuTTY with both Visual Studio
   7 (2003) and Visual Studio 14 (2015), so our guess is that it will
   probably build with versions in between those as well.

   (The binaries from Visual Studio 14 are only compatible with
   Windows XP and up. Binaries from Visual Studio 7 ought to work
   with anything from Windows 95 onward.)

 - Inside the windows/MSVC subdirectory are MS Visual Studio project
   files for doing GUI-based builds of the various PuTTY utilities.
   These have been tested on Visual Studio 7 and 10.

   You should be able to build each PuTTY utility by loading the
   corresponding .dsp file in Visual Studio. For example,
   MSVC/putty/putty.dsp builds PuTTY itself, MSVC/plink/plink.dsp
   builds Plink, and so on.

 - windows/Makefile.mgw is for MinGW / Cygwin installations. Type
   `make -f Makefile.mgw' while in the `windows' subdirectory to
   build all the PuTTY binaries.

   MinGW and friends can lag behind other toolchains in their support
   for the Windows API. Compile-time levers are provided to exclude
   some features; the defaults are set appropriately for the
   'mingw-w64' cross-compiler provided with Ubuntu 14.04. If you are
   using an older toolchain, you may need to exclude more features;
   alternatively, you may find that upgrading to a recent version of
   the 'w32api' package helps.

 - windows/Makefile.lcc is for lcc-win32. Type `make -f
   Makefile.lcc' while in the `windows' subdirectory. (You will
   probably need to specify COMPAT=-DNO_MULTIMON.)

 - Inside the windows/DEVCPP subdirectory are Dev-C++ project
   files for doing GUI-based builds of the various PuTTY utilities.

The PuTTY team actively use Makefile.vc (with VC7/10) and Makefile.mgw
(with mingw32), so we'll probably notice problems with those
toolchains fairly quickly. Please report any problems with the other
toolchains mentioned above.

For building on Unix:

 - unix/configure is for Unix and GTK. If you don't have GTK, you
   should still be able to build the command-line utilities (PSCP,
   PSFTP, Plink, PuTTYgen) using this script. To use it, change into
   the `unix' subdirectory, run `./configure' and then `make'. Or you
   can do the same in the top-level directory (we provide a little
   wrapper that invokes configure one level down), which is more like
   a normal Unix source archive but doesn't do so well at keeping the
   per-platform stuff in each platform's subdirectory; it's up to you.

 - unix/Makefile.gtk and unix/Makefile.ux are for non-autoconfigured
   builds. These makefiles expect you to change into the `unix'
   subdirectory, then run `make -f Makefile.gtk' or `make -f
   Makefile.ux' respectively. Makefile.gtk builds all the programs but
   relies on Gtk, whereas Makefile.ux builds only the command-line
   utilities and has no Gtk dependence.

 - For the graphical utilities, any of Gtk+-1.2, Gtk+-2.0, and Gtk+-3.0
   should be supported. If you have more than one installed, you can
   manually specify which one you want by giving the option
   '--with-gtk=N' to the configure script where N is 1, 2, or 3.
   (The default is the newest available, of course.) In the absence
   of any Gtk version, the configure script will automatically
   construct a Makefile which builds only the command-line utilities;
   you can manually create this condition by giving configure the
   option '--without-gtk'.

 - pterm would like to be setuid or setgid, as appropriate, to permit
   it to write records of user logins to /var/run/utmp and
   /var/log/wtmp. (Of course it will not use this privilege for
   anything else, and in particular it will drop all privileges before
   starting up complex subsystems like GTK.) By default the makefile
   will not attempt to add privileges to the pterm executable at 'make
   install' time, but you can ask it to do so by running configure
   with the option '--enable-setuid=USER' or '--enable-setgid=GROUP'.

 - The Unix Makefiles have an `install' target. Note that by default
   it tries to install `man' pages; if you have fetched the source via
   Git then you will need to have built these using Halibut
   first - see below.

 - It's also possible to build the Windows version of PuTTY to run
   on Unix by using Winelib.  To do this, change to the `windows'
   directory and run `make -f Makefile.mgw CC=winegcc RC=wrc'.

All of the Makefiles are generated automatically from the file
`Recipe' by the Perl script `mkfiles.pl' (except for the Unix one,
which is generated by the `configure' script; mkfiles.pl only
generates the input to automake). Additions and corrections to Recipe,
mkfiles.pl and/or configure.ac are much more useful than additions and
corrections to the actual Makefiles, Makefile.am or Makefile.in.

The Unix `configure' script and its various requirements are generated
by the shell script `mkauto.sh', which requires GNU Autoconf, GNU
Automake, and Gtk; if you've got the source from Git rather
than using one of our source snapshots, you'll need to run this
yourself. The input file to Automake is generated by mkfiles.pl along
with all the rest of the makefiles, so you will need to run mkfiles.pl
and then mkauto.sh.

Documentation (in various formats including Windows Help and Unix
`man' pages) is built from the Halibut (`.but') files in the `doc'
subdirectory using `doc/Makefile'. If you aren't using one of our
source snapshots, you'll need to do this yourself. Halibut can be
found at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.

The PuTTY home web site is

    https://www.chiark.greenend.org.uk/~sgtatham/putty/

If you want to send bug reports or feature requests, please read the
Feedback section of the web site before doing so. Sending one-line
reports saying `it doesn't work' will waste your time as much as
ours.

See the file LICENCE for the licence conditions.
Description
No description provided
Readme 340 MiB
Languages
C 89.7%
Python 8%
Perl 0.9%
CMake 0.8%
Shell 0.4%
Other 0.1%