mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-10 01:48:00 +00:00
b94c6a7e38
This is a major code reorganisation in preparation for making this code base into one that can build an SSH server as well as a client. (Mostly for purposes of using the server as a regression test suite for the client, though I have some other possible uses in mind too. However, it's currently no part of my plan to harden the server to the point where it can sensibly be deployed in a hostile environment.) In this preparatory commit, I've broken up the SSH-2 transport and connection layers, and the SSH-1 connection layer, into multiple source files, with each layer having its own header file containing the shared type definitions. In each case, the new source file contains code that's specific to the client side of the protocol, so that a new file can be swapped in in its place when building the server. Mostly this is just a straightforward moving of code without changing it very much, but there are a couple of actual changes in the process: The parsing of SSH-2 global-request and channel open-messages is now done by a new pair of functions in the client module. For channel opens, I've invented a new union data type to be the return value from that function, representing either failure (plus error message), success (plus Channel instance to manage the new channel), or an instruction to hand the channel over to a sharing downstream (plus a pointer to the downstream in question). Also, the tree234 of remote port forwardings in ssh2connection is now initialised on first use by the client-specific code, so that's where its compare function lives. The shared ssh2connection_free() still takes responsibility for freeing it, but now has to check if it's non-null first. The outer shell of the ssh2_lportfwd_open method, for making a local-to-remote port forwarding, is still centralised in ssh2connection.c, but the part of it that actually constructs the outgoing channel-open message has moved into the client code, because that will have to change depending on whether the channel-open has to have type direct-tcpip or forwarded-tcpip. In the SSH-1 connection layer, half the filter_queue method has moved out into the new client-specific code, but not all of it - bidirectional channel maintenance messages are still handled centrally. One exception is SSH_MSG_PORT_OPEN, which can be sent in both directions, but with subtly different semantics - from server to client, it's referring to a previously established remote forwarding (and must be rejected if there isn't one that matches it), but from client to server it's just a "direct-tcpip" request with no prior context. So that one is in the client-specific module, and when I add the server code it will have its own different handler. |
||
|---|---|---|
| charset | ||
| contrib | ||
| doc | ||
| icons | ||
| testdata | ||
| unix | ||
| windows | ||
| .gitignore | ||
| agentf.c | ||
| aqsync.c | ||
| be_all_s.c | ||
| be_all.c | ||
| be_misc.c | ||
| be_none.c | ||
| be_nos_s.c | ||
| be_nossh.c | ||
| be_ssh.c | ||
| Buildscr | ||
| Buildscr.cv | ||
| callback.c | ||
| cgtest.c | ||
| CHECKLST.txt | ||
| cmdgen.c | ||
| cmdline.c | ||
| conf.c | ||
| config.c | ||
| configure.ac | ||
| cproxy.c | ||
| defs.h | ||
| dialog.c | ||
| dialog.h | ||
| errsock.c | ||
| fuzzterm.c | ||
| import.c | ||
| int64.c | ||
| int64.h | ||
| LATEST.VER | ||
| ldisc.c | ||
| ldisc.h | ||
| ldiscucs.c | ||
| LICENCE | ||
| licence.pl | ||
| logging.c | ||
| mainchan.c | ||
| marshal.c | ||
| marshal.h | ||
| minibidi.c | ||
| misc.c | ||
| misc.h | ||
| miscucs.c | ||
| mkauto.sh | ||
| mkfiles.pl | ||
| mksrcarc.sh | ||
| mkunxarc.sh | ||
| network.h | ||
| nocmdline.c | ||
| nocproxy.c | ||
| nogss.c | ||
| noprint.c | ||
| noshare.c | ||
| noterm.c | ||
| notiming.c | ||
| nullplug.c | ||
| pageant.c | ||
| pageant.h | ||
| pgssapi.c | ||
| pgssapi.h | ||
| pinger.c | ||
| portfwd.c | ||
| pproxy.c | ||
| proxy.c | ||
| proxy.h | ||
| pscp.c | ||
| psftp.c | ||
| psftp.h | ||
| putty.h | ||
| puttymem.h | ||
| puttyps.h | ||
| raw.c | ||
| README | ||
| Recipe | ||
| release.pl | ||
| resource.h | ||
| rlogin.c | ||
| sercfg.c | ||
| sessprep.c | ||
| settings.c | ||
| sftp.c | ||
| sftp.h | ||
| sign.sh | ||
| ssh1bpp.c | ||
| ssh1censor.c | ||
| ssh1connection-client.c | ||
| ssh1connection.c | ||
| ssh1connection.h | ||
| ssh1login.c | ||
| ssh2bpp-bare.c | ||
| ssh2bpp.c | ||
| ssh2censor.c | ||
| ssh2connection-client.c | ||
| ssh2connection.c | ||
| ssh2connection.h | ||
| ssh2kex-client.c | ||
| ssh2transhk.c | ||
| ssh2transport.c | ||
| ssh2transport.h | ||
| ssh2userauth.c | ||
| ssh.c | ||
| ssh.h | ||
| sshaes.c | ||
| ssharcf.c | ||
| sshbcrypt.c | ||
| sshblowf.c | ||
| sshblowf.h | ||
| sshbn.c | ||
| sshbn.h | ||
| sshbpp.h | ||
| sshccp.c | ||
| sshchan.h | ||
| sshcommon.c | ||
| sshcr.h | ||
| sshcrc.c | ||
| sshcrcda.c | ||
| sshdes.c | ||
| sshdh.c | ||
| sshdss.c | ||
| sshdssg.c | ||
| sshecc.c | ||
| sshecdsag.c | ||
| sshgss.h | ||
| sshgssc.c | ||
| sshgssc.h | ||
| sshmac.c | ||
| sshmd5.c | ||
| sshnogss.c | ||
| sshppl.h | ||
| sshprime.c | ||
| sshpubk.c | ||
| sshrand.c | ||
| sshrsa.c | ||
| sshrsag.c | ||
| sshsh256.c | ||
| sshsh512.c | ||
| sshsha.c | ||
| sshshare.c | ||
| sshsignals.h | ||
| sshttymodes.h | ||
| sshverstring.c | ||
| sshzlib.c | ||
| storage.h | ||
| telnet.c | ||
| terminal.c | ||
| terminal.h | ||
| testback.c | ||
| testbn.c | ||
| time.c | ||
| timing.c | ||
| tree234.c | ||
| tree234.h | ||
| version.c | ||
| version.h | ||
| wcwidth.c | ||
| wildcard.c | ||
| x11fwd.c | ||
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.