1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-03-13 10:33:51 -05:00
Simon Tatham 7db526c730 Clean up elliptic curve selection and naming.
The ec_name_to_curve and ec_curve_to_name functions shouldn't really
have had to exist at all: whenever any part of the PuTTY codebase
starts using sshecc.c, it's starting from an ssh_signkey or ssh_kex
pointer already found by some other means. So if we make sure not to
lose that pointer, we should never need to do any string-based lookups
to find the curve we want, and conversely, when we need to know the
name of our curve or our algorithm, we should be able to look it up as
a straightforward const char * starting from the algorithm pointer.

This commit cleans things up so that that is indeed what happens. The
ssh_signkey and ssh_kex structures defined in sshecc.c now have
'extra' fields containing pointers to all the necessary stuff;
ec_name_to_curve and ec_curve_to_name have been completely removed;
struct ec_curve has a string field giving the curve's name (but only
for those curves which _have_ a name exposed in the wire protocol,
i.e. the three NIST ones); struct ec_key keeps a pointer to the
ssh_signkey it started from, and uses that to remember the algorithm
name rather than reconstructing it from the curve. And I think I've
got rid of all the ad-hockery scattered around the code that switches
on curve->fieldBits or manually constructs curve names using stuff
like sprintf("nistp%d"); the only remaining switch on fieldBits
(necessary because that's the UI for choosing a curve in PuTTYgen) is
at least centralised into one place in sshecc.c.

One user-visible result is that the format of ed25519 host keys in the
registry has changed: there's now no curve name prefix on them,
because I think it's not really right to make up a name to use. So any
early adopters who've been using snapshot PuTTY in the last week will
be inconvenienced; sorry about that.
2015-05-15 10:15:35 +01:00
2015-04-25 10:54:18 +01:00
2015-02-28 07:57:35 +00:00
2015-02-28 15:47:45 +00:00
2014-11-22 15:26:16 +00:00
2006-08-05 13:48:53 +00:00
2015-01-05 23:49:25 +00:00
2014-11-09 00:54:35 +00:00
2012-09-18 21:42:48 +00:00
2012-09-18 21:42:48 +00:00
2014-12-20 18:52:40 +00:00
2014-11-22 16:35:54 +00:00
1999-01-08 13:02:13 +00:00
2015-04-25 10:54:18 +01:00
2015-04-27 20:48:29 +01:00
2015-05-12 12:14:45 +01:00
2015-05-15 10:12:05 +01:00

This is the README for the source archive of PuTTY, a free Win32
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.

   Last time we checked, PuTTY built with vanilla VC7, or VC6 with
   an up-to-date Platform SDK. (It might still be possible to build
   with vanilla VC6, but you'll certainly have to remove some
   functionality with directives such as NO_IPV6.)

   (We've also had reports of success building with the
   OpenWatcom compiler -- www.openwatcom.org -- using Makefile.vc
   with `wmake -ms -f makefile.vc' and NO_MULTIMON, although we
   haven't tried this ourselves. Version 1.3 is reported to work.)

 - 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 6.

   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.bor is for the Borland C compiler. Type `make -f
   Makefile.bor' while in the `windows' subdirectory to build all
   the PuTTY binaries.

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

   You'll probably need quite a recent version of the w32api package.
   Note that by default the multiple monitor and HTML Help support are
   excluded from the Cygwin build, since at the time of writing Cygwin
   doesn't include the necessary headers.

 - 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) and Makefile.cyg
(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.

   Note that Unix PuTTY has mostly only been tested on Linux so far;
   portability problems such as BSD-style ptys or different header file
   requirements are expected.

 - 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, Gtk+-1.2 and Gtk+-2.0 should both be
   supported. If you have both installed, you can manually specify
   which one you want by giving the option '--with-gtk=1' or
   '--with-gtk=2' to the configure script. (2 is the default, of
   course.) In the absence of either, 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.cyg 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 <http://www.chiark.greenend.org.uk/~sgtatham/halibut/>.

The PuTTY home web site is

    http://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%