2002-03-16 18:49:28 +03:00
|
|
|
# -*- makefile -*-
|
|
|
|
|
#
|
|
|
|
|
# This file describes which PuTTY programs are made up from which
|
|
|
|
|
# object and resource files. It is processed into the various
|
|
|
|
|
# Makefiles by means of a Perl script. Makefile changes should
|
|
|
|
|
# really be made by editing this file and/or the Perl script, not
|
|
|
|
|
# by editing the actual Makefiles.
|
|
|
|
|
|
2004-04-25 13:04:38 +04:00
|
|
|
# ------------------------------------------------------------
|
|
|
|
|
# Top-level configuration.
|
|
|
|
|
|
|
|
|
|
# Overall project name.
|
|
|
|
|
!name putty
|
|
|
|
|
# Locations and types of output Makefiles.
|
2017-02-05 13:59:08 +03:00
|
|
|
!makefile clangcl windows/Makefile.clangcl
|
2004-11-17 01:14:56 +03:00
|
|
|
!makefile vc windows/Makefile.vc
|
|
|
|
|
!makefile vcproj windows/MSVC
|
2016-04-10 16:26:54 +03:00
|
|
|
!makefile cygwin windows/Makefile.mgw
|
2004-11-17 01:14:56 +03:00
|
|
|
!makefile lcc windows/Makefile.lcc
|
2004-04-25 13:04:38 +04:00
|
|
|
!makefile gtk unix/Makefile.gtk
|
2009-05-11 22:48:43 +04:00
|
|
|
!makefile unix unix/Makefile.ux
|
2014-02-22 22:01:32 +04:00
|
|
|
!makefile am Makefile.am
|
2005-08-23 00:37:13 +04:00
|
|
|
!makefile devcppproj windows/DEVCPP
|
2014-01-11 15:23:12 +04:00
|
|
|
!makefile vstudio10 windows/VS2010
|
|
|
|
|
!makefile vstudio12 windows/VS2012
|
2004-04-25 13:26:52 +04:00
|
|
|
# Source directories.
|
|
|
|
|
!srcdir charset/
|
2004-11-17 01:14:56 +03:00
|
|
|
!srcdir windows/
|
2004-04-25 13:26:52 +04:00
|
|
|
!srcdir unix/
|
2004-04-25 13:04:38 +04:00
|
|
|
|
2002-03-16 18:49:28 +03:00
|
|
|
# Help text added to the top of each Makefile, with /D converted
|
|
|
|
|
# into -D as appropriate for the particular Makefile.
|
|
|
|
|
|
|
|
|
|
!begin help
|
|
|
|
|
#
|
|
|
|
|
# Extra options you can set:
|
|
|
|
|
#
|
2005-05-21 18:35:21 +04:00
|
|
|
# - COMPAT=/DAUTO_WINSOCK (Windows only)
|
2002-03-16 18:49:28 +03:00
|
|
|
# Causes PuTTY to assume that <windows.h> includes its own WinSock
|
|
|
|
|
# header file, so that it won't try to include <winsock.h>.
|
|
|
|
|
#
|
2005-05-21 18:35:21 +04:00
|
|
|
# - COMPAT=/DWINSOCK_TWO (Windows only)
|
2002-03-16 18:49:28 +03:00
|
|
|
# Causes the PuTTY utilities to include <winsock2.h> instead of
|
|
|
|
|
# <winsock.h>, except Plink which _needs_ WinSock 2 so it already
|
|
|
|
|
# does this.
|
|
|
|
|
#
|
2005-05-21 18:35:21 +04:00
|
|
|
# - COMPAT=/DNO_SECURITY (Windows only)
|
2016-04-10 16:37:43 +03:00
|
|
|
# Disables use of <aclapi.h>, which is not available with some
|
|
|
|
|
# development environments (such as very old versions of the
|
|
|
|
|
# mingw/Cygwin GNU toolchain). This has the following effects:
|
|
|
|
|
# - Pageant won't care about the local user ID of processes
|
|
|
|
|
# accessing it; a version of Pageant built with this option
|
|
|
|
|
# will therefore refuse to run under NT-series OSes on
|
|
|
|
|
# security grounds (although it will run fine on Win95-series
|
|
|
|
|
# OSes where there is no access control anyway).
|
|
|
|
|
# - SSH connection sharing is disabled.
|
2017-01-29 00:56:28 +03:00
|
|
|
# - There is no support for restriction of the process ACLs.
|
2002-03-16 18:49:28 +03:00
|
|
|
#
|
2005-05-21 18:35:21 +04:00
|
|
|
# - COMPAT=/DNO_MULTIMON (Windows only)
|
2002-03-16 18:49:28 +03:00
|
|
|
# Disables PuTTY's use of <multimon.h>, which is not available
|
|
|
|
|
# with some development environments. This means that PuTTY's
|
|
|
|
|
# full-screen mode (configurable to work on Alt-Enter) will
|
|
|
|
|
# not behave usefully in a multi-monitor environment.
|
|
|
|
|
#
|
2006-12-28 23:56:01 +03:00
|
|
|
# - COMPAT=/DNO_HTMLHELP (Windows only)
|
|
|
|
|
# Disables PuTTY's use of <htmlhelp.h>, which is not available
|
|
|
|
|
# with some development environments. The resulting binary
|
|
|
|
|
# will only look for an old-style WinHelp file (.HLP/.CNT), and
|
|
|
|
|
# will ignore any .CHM file.
|
|
|
|
|
#
|
2016-04-10 16:40:39 +03:00
|
|
|
# If you don't have this header, you may be able to use the copy
|
|
|
|
|
# supplied with HTML Help Workshop.
|
2006-12-28 23:56:01 +03:00
|
|
|
#
|
2005-05-21 19:09:36 +04:00
|
|
|
# - RCFL=/DNO_MANIFESTS (Windows only)
|
2005-05-21 18:35:21 +04:00
|
|
|
# Disables inclusion of XML application manifests in the PuTTY
|
|
|
|
|
# binaries. This may be necessary to build for 64-bit Windows;
|
|
|
|
|
# the manifests are only included to use the XP GUI style on
|
|
|
|
|
# Windows XP, and the architecture tags are a lie on 64-bit.
|
|
|
|
|
#
|
2004-12-30 19:45:11 +03:00
|
|
|
# - COMPAT=/DNO_IPV6
|
|
|
|
|
# Disables PuTTY's ability to make IPv6 connections, enabling
|
|
|
|
|
# it to compile under development environments which do not
|
|
|
|
|
# support IPv6 in their header files.
|
|
|
|
|
#
|
2008-08-10 17:10:31 +04:00
|
|
|
# - COMPAT=/DNO_GSSAPI
|
|
|
|
|
# Disables PuTTY's ability to use GSSAPI functions for
|
|
|
|
|
# authentication and key exchange.
|
|
|
|
|
#
|
2010-05-19 22:22:17 +04:00
|
|
|
# - COMPAT=/DSTATIC_GSSAPI
|
|
|
|
|
# Causes PuTTY to try to link statically against the GSSAPI
|
|
|
|
|
# library instead of the default of doing it at run time.
|
|
|
|
|
#
|
2005-05-21 18:35:21 +04:00
|
|
|
# - COMPAT=/DMSVC4 (Windows only)
|
2002-03-16 18:49:28 +03:00
|
|
|
# - RCFL=/DMSVC4
|
|
|
|
|
# Makes a couple of minor changes so that PuTTY compiles using
|
|
|
|
|
# MSVC 4. You will also need /DNO_SECURITY and /DNO_MULTIMON.
|
|
|
|
|
#
|
2012-09-19 03:05:29 +04:00
|
|
|
# - COMPAT=/DNO_SECUREZEROMEMORY (Windows only)
|
|
|
|
|
# Disables PuTTY's use of SecureZeroMemory(), which is missing
|
2016-04-10 16:40:39 +03:00
|
|
|
# from some environments' header files.
|
2012-09-19 03:05:29 +04:00
|
|
|
#
|
2003-01-15 18:22:58 +03:00
|
|
|
# - XFLAGS=/DTELNET_DEFAULT
|
|
|
|
|
# Causes PuTTY to default to the Telnet protocol (in the absence
|
|
|
|
|
# of Default Settings and so on to the contrary). Normally PuTTY
|
|
|
|
|
# will default to SSH.
|
|
|
|
|
#
|
2002-03-16 18:49:28 +03:00
|
|
|
# - XFLAGS=/DDEBUG
|
|
|
|
|
# Causes PuTTY to enable internal debugging.
|
|
|
|
|
#
|
|
|
|
|
# - XFLAGS=/DMALLOC_LOG
|
|
|
|
|
# Causes PuTTY to emit a file called putty_mem.log, logging every
|
|
|
|
|
# memory allocation and free, so you can track memory leaks.
|
|
|
|
|
#
|
2005-05-21 18:35:21 +04:00
|
|
|
# - XFLAGS=/DMINEFIELD (Windows only)
|
2002-03-16 18:49:28 +03:00
|
|
|
# Causes PuTTY to use a custom memory allocator, similar in
|
|
|
|
|
# concept to Electric Fence, in place of regular malloc(). Wastes
|
|
|
|
|
# huge amounts of RAM, but should cause heap-corruption bugs to
|
|
|
|
|
# show up as GPFs at the point of failure rather than appearing
|
|
|
|
|
# later on as second-level damage.
|
|
|
|
|
#
|
2015-10-17 18:26:51 +03:00
|
|
|
# - XFLAGS=/DFUZZING
|
|
|
|
|
# Builds a version of PuTTY with some tweaks to make fuzz testing
|
|
|
|
|
# easier: the SSH random number generator is replaced by one that
|
|
|
|
|
# always returns the same thing. Note that this makes SSH
|
|
|
|
|
# completely insecure -- a FUZZING build should never be used to
|
|
|
|
|
# connect to a real server.
|
2002-03-16 18:49:28 +03:00
|
|
|
!end
|
|
|
|
|
|
2004-04-25 13:04:38 +04:00
|
|
|
# ------------------------------------------------------------
|
|
|
|
|
# Additional text added verbatim to each individual Makefile.
|
|
|
|
|
|
2017-01-21 17:57:31 +03:00
|
|
|
!cflags am version
|
Show the git commit hash in local dev builds too.
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
2017-01-21 17:57:31 +03:00
|
|
|
!begin am
|
2017-01-21 17:57:31 +03:00
|
|
|
if AUTO_GIT_COMMIT
|
Show the git commit hash in local dev builds too.
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
2017-01-21 17:57:31 +03:00
|
|
|
BUILT_SOURCES = empty.h
|
|
|
|
|
CLEANFILES = empty.h
|
2017-01-21 17:57:31 +03:00
|
|
|
libversion_a_CFLAGS += -DSOURCE_COMMIT=\"`git --git-dir=$(srcdir)/.git rev-parse HEAD 2>/dev/null`\"
|
Show the git commit hash in local dev builds too.
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
2017-01-21 17:57:31 +03:00
|
|
|
empty.h: $(allsources)
|
|
|
|
|
echo '/* Empty file touched by automake makefile to force rebuild of version.o */' >$@
|
2017-01-21 17:57:31 +03:00
|
|
|
endif
|
2019-01-25 23:15:24 +03:00
|
|
|
|
|
|
|
|
# Run the cryptsuite tests as part of 'make check'. Override
|
|
|
|
|
# PUTTY_TESTCRYPT so that cryptsuite will take the testcrypt binary
|
|
|
|
|
# from the build directory instead of the source directory, in case
|
|
|
|
|
# this is an out-of-tree build.
|
|
|
|
|
check-local: testcrypt
|
|
|
|
|
PUTTY_TESTCRYPT=./testcrypt $(srcdir)/test/cryptsuite.py
|
|
|
|
|
|
Show the git commit hash in local dev builds too.
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
2017-01-21 17:57:31 +03:00
|
|
|
!end
|
|
|
|
|
!begin >empty.h
|
|
|
|
|
/* Empty file touched by automake makefile to force rebuild of version.o */
|
|
|
|
|
!end
|
|
|
|
|
|
2005-10-04 18:13:28 +04:00
|
|
|
!begin vc vars
|
2014-11-01 17:44:16 +03:00
|
|
|
CFLAGS = $(CFLAGS) /DHAS_GSSAPI
|
2005-10-04 18:13:28 +04:00
|
|
|
!end
|
|
|
|
|
|
2017-02-05 13:59:08 +03:00
|
|
|
!begin clangcl vars
|
|
|
|
|
CFLAGS += /DHAS_GSSAPI
|
|
|
|
|
!end
|
|
|
|
|
|
2004-04-25 13:04:38 +04:00
|
|
|
# `make install' target for Unix.
|
|
|
|
|
!begin gtk
|
|
|
|
|
install:
|
2007-05-01 00:09:58 +04:00
|
|
|
mkdir -p $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir)
|
2017-03-05 23:33:49 +03:00
|
|
|
$(INSTALL_PROGRAM) -m 755 pageant $(DESTDIR)$(bindir)/pageant
|
2004-04-25 13:04:38 +04:00
|
|
|
$(INSTALL_PROGRAM) -m 755 plink $(DESTDIR)$(bindir)/plink
|
|
|
|
|
$(INSTALL_PROGRAM) -m 755 pscp $(DESTDIR)$(bindir)/pscp
|
|
|
|
|
$(INSTALL_PROGRAM) -m 755 psftp $(DESTDIR)$(bindir)/psftp
|
|
|
|
|
$(INSTALL_PROGRAM) -m 755 pterm $(DESTDIR)$(bindir)/pterm
|
2005-01-11 13:45:43 +03:00
|
|
|
if test -n "$(UTMP_GROUP)"; then \
|
|
|
|
|
chgrp $(UTMP_GROUP) $(DESTDIR)$(bindir)/pterm && \
|
|
|
|
|
chmod 2755 $(DESTDIR)$(bindir)/pterm; \
|
|
|
|
|
elif test -n "$(UTMP_USER)"; then \
|
|
|
|
|
chown $(UTMP_USER) $(DESTDIR)$(bindir)/pterm && \
|
|
|
|
|
chmod 4755 $(DESTDIR)$(bindir)/pterm; \
|
|
|
|
|
fi
|
2004-04-25 13:04:38 +04:00
|
|
|
$(INSTALL_PROGRAM) -m 755 putty $(DESTDIR)$(bindir)/putty
|
|
|
|
|
$(INSTALL_PROGRAM) -m 755 puttygen $(DESTDIR)$(bindir)/puttygen
|
|
|
|
|
$(INSTALL_PROGRAM) -m 755 puttytel $(DESTDIR)$(bindir)/puttytel
|
2017-03-05 23:33:49 +03:00
|
|
|
$(INSTALL_DATA) -m 644 ../doc/pageant.1 $(DESTDIR)$(man1dir)/pageant.1
|
2004-04-25 13:04:38 +04:00
|
|
|
$(INSTALL_DATA) -m 644 ../doc/plink.1 $(DESTDIR)$(man1dir)/plink.1
|
|
|
|
|
$(INSTALL_DATA) -m 644 ../doc/pscp.1 $(DESTDIR)$(man1dir)/pscp.1
|
|
|
|
|
$(INSTALL_DATA) -m 644 ../doc/psftp.1 $(DESTDIR)$(man1dir)/psftp.1
|
|
|
|
|
$(INSTALL_DATA) -m 644 ../doc/pterm.1 $(DESTDIR)$(man1dir)/pterm.1
|
|
|
|
|
$(INSTALL_DATA) -m 644 ../doc/putty.1 $(DESTDIR)$(man1dir)/putty.1
|
|
|
|
|
$(INSTALL_DATA) -m 644 ../doc/puttygen.1 $(DESTDIR)$(man1dir)/puttygen.1
|
|
|
|
|
$(INSTALL_DATA) -m 644 ../doc/puttytel.1 $(DESTDIR)$(man1dir)/puttytel.1
|
|
|
|
|
|
|
|
|
|
install-strip:
|
|
|
|
|
$(MAKE) install INSTALL_PROGRAM="$(INSTALL_PROGRAM) -s"
|
|
|
|
|
!end
|
|
|
|
|
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 15:33:29 +04:00
|
|
|
# List the man pages for the automake makefile.
|
|
|
|
|
!begin am
|
2017-02-22 01:17:48 +03:00
|
|
|
if HAVE_GTK
|
|
|
|
|
man1_MANS = doc/plink.1 doc/pscp.1 doc/psftp.1 doc/puttygen.1 \
|
2017-02-22 01:24:26 +03:00
|
|
|
doc/pageant.1 doc/pterm.1 doc/putty.1 doc/puttytel.1
|
2017-02-22 01:17:48 +03:00
|
|
|
else
|
|
|
|
|
man1_MANS = doc/plink.1 doc/pscp.1 doc/psftp.1 doc/puttygen.1
|
|
|
|
|
endif
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 15:33:29 +04:00
|
|
|
!end
|
|
|
|
|
|
|
|
|
|
# In automake, chgrp/chmod pterm after installation, if configured to.
|
|
|
|
|
!begin am
|
|
|
|
|
if HAVE_SETID_CMD
|
|
|
|
|
install-exec-local:
|
|
|
|
|
@SETID_CMD@ $(bindir)/pterm
|
|
|
|
|
chmod @SETID_MODE@ $(bindir)/pterm
|
|
|
|
|
endif
|
|
|
|
|
!end
|
|
|
|
|
|
2016-03-24 01:14:13 +03:00
|
|
|
# In automake makefile, build the OS X app bundle, if configured in
|
|
|
|
|
# Quartz mode.
|
|
|
|
|
!begin am
|
|
|
|
|
if HAVE_QUARTZ
|
|
|
|
|
noinst_SCRIPTS = unix/PuTTY.app unix/Pterm.app
|
|
|
|
|
unix/PuTTY.app: unix/putty.bundle puttyapp osxlaunch
|
2017-11-26 13:58:56 +03:00
|
|
|
rm -rf $@ && PUTTY_GTK_PREFIX_FROM_MAKEFILE=$$(pkg-config --variable=prefix gtk+-3.0) gtk-mac-bundler $<
|
2016-03-24 01:14:13 +03:00
|
|
|
unix/Pterm.app: unix/pterm.bundle ptermapp osxlaunch
|
2017-11-26 13:58:56 +03:00
|
|
|
rm -rf $@ && PUTTY_GTK_PREFIX_FROM_MAKEFILE=$$(pkg-config --variable=prefix gtk+-3.0) gtk-mac-bundler $<
|
2016-03-24 01:14:13 +03:00
|
|
|
endif
|
|
|
|
|
!end
|
|
|
|
|
|
2007-01-10 02:47:15 +03:00
|
|
|
# Random symbols.
|
|
|
|
|
!begin cygwin vars
|
|
|
|
|
# _WIN32_IE is required to expose identifiers that only make sense on
|
|
|
|
|
# systems with IE5+ installed, such as some arguments to SHGetFolderPath().
|
2007-01-16 23:54:58 +03:00
|
|
|
# WINVER etc perform a similar function for FlashWindowEx().
|
2007-01-10 02:47:15 +03:00
|
|
|
CFLAGS += -D_WIN32_IE=0x0500
|
2007-01-16 23:54:58 +03:00
|
|
|
CFLAGS += -DWINVER=0x0500 -D_WIN32_WINDOWS=0x0410 -D_WIN32_WINNT=0x0500
|
2007-01-10 02:47:15 +03:00
|
|
|
!end
|
|
|
|
|
|
2004-04-25 13:04:38 +04:00
|
|
|
# ------------------------------------------------------------
|
2002-03-16 18:49:28 +03:00
|
|
|
# Definitions of object groups. A group name, followed by an =,
|
|
|
|
|
# followed by any number of objects or other already-defined group
|
|
|
|
|
# names. A line beginning `+' is assumed to continue the previous
|
|
|
|
|
# line.
|
|
|
|
|
|
2018-05-24 12:48:20 +03:00
|
|
|
# conf.c and its dependencies.
|
|
|
|
|
CONF = conf marshal
|
|
|
|
|
|
2004-05-22 14:36:50 +04:00
|
|
|
# Terminal emulator and its (platform-independent) dependencies.
|
|
|
|
|
TERMINAL = terminal wcwidth ldiscucs logging tree234 minibidi
|
2018-05-24 12:48:20 +03:00
|
|
|
+ config dialog CONF
|
2004-05-22 14:36:50 +04:00
|
|
|
|
2002-03-16 18:49:28 +03:00
|
|
|
# GUI front end and terminal emulator (putty, puttytel).
|
2017-04-03 22:30:18 +03:00
|
|
|
GUITERM = TERMINAL window windlg winctrls sizetip winprint winutils
|
2017-12-03 17:35:03 +03:00
|
|
|
+ wincfg sercfg winhelp winjump sessprep
|
2002-03-16 18:49:28 +03:00
|
|
|
|
2003-04-27 15:10:48 +04:00
|
|
|
# Same thing on Unix.
|
2015-07-27 22:06:02 +03:00
|
|
|
UXTERM = TERMINAL uxcfg sercfg uxucs uxprint timing callback miscucs
|
Divide the whole of gtkwin.c into three parts.
This lays further groundwork for the OS X GTK3 port, which is going to
have to deal with multiple sessions sharing the same process. gtkwin.c
was a bit too monolithic for this, since it included some
process-global runtime state (timers, toplevel callbacks), some
process startup stuff (gtk_init, gtk_main, argv processing) and some
per-session-window stuff.
The per-session stuff remains in gtkwin.c, with the top-level function
now being new_session_window() taking a Conf. The new gtkmain.c
contains the outer skeleton of pt_main(), handling argv processing and
one-off startup stuff like setlocale; and the new gtkcomm.c contains
the pieces of PuTTY infrastructure like timers and uxsel that are
shared between multiple sessions rather than reinstantiated per
session, which have been rewritten to use global variables rather than
fields in 'inst' (since it's now clear to me that they'll have to
apply to all the insts in existence at once).
There are still some lurking assumptions of one-session-per-process,
e.g. the use of gtk_main_quit when a session finishes, and the fact
that the config box insists on running as a separate invocation of
gtk_main so that one session's preliminary config box can't coexist
with another session already active. But this should make it possible
to at least write an OS X app good enough to start testing with, even
if it doesn't get everything quite right yet.
This change is almost entirely rearranging existing code, so it
shouldn't be seriously destabilising. But two noticeable actual
changes have happened, both pleasantly simplifying:
Firstly, the global-variables rewrite of gtkcomm.c has allowed the
post_main edifice to become a great deal simpler. Most of its
complexity was about remembering what 'inst' it had to call back to,
and in fact the right answer is that it shouldn't be calling back to
one at all. So now the post_main() called by gtkdlg.c has become the
same function as the old inst_post_main() that actually did the work,
instead of the two having to be connected by a piece of ugly plumbing.
Secondly, a piece of code that's vanished completely in this
refactoring is the temporary blocking of SIGCHLD around most of the
session setup code. This turns out to have been introduced in 2002,
_before_ I switched to using the intra-process signal pipe strategy
for SIGCHLD handling in 2003. So I now expect that we should be robust
in any case against receiving SIGCHLD at an inconvenient moment, and
hence there's no need to block it.
2016-03-23 00:24:30 +03:00
|
|
|
GTKTERM = UXTERM gtkwin gtkcfg gtkdlg gtkfont gtkcols gtkmisc xkeysym
|
2017-12-03 17:35:03 +03:00
|
|
|
+ x11misc gtkcomm sessprep
|
2017-11-27 22:38:02 +03:00
|
|
|
GTKMAIN = gtkmain cmdline
|
2003-03-29 22:52:50 +03:00
|
|
|
|
2002-03-16 18:49:28 +03:00
|
|
|
# Non-SSH back ends (putty, puttytel, plink).
|
2004-11-27 16:20:21 +03:00
|
|
|
NONSSH = telnet raw rlogin ldisc pinger
|
2002-03-16 18:49:28 +03:00
|
|
|
|
|
|
|
|
# SSH back end (putty, plink, pscp, psftp).
|
Complete rewrite of PuTTY's bignum library.
The old 'Bignum' data type is gone completely, and so is sshbn.c. In
its place is a new thing called 'mp_int', handled by an entirely new
library module mpint.c, with API differences both large and small.
The main aim of this change is that the new library should be free of
timing- and cache-related side channels. I've written the code so that
it _should_ - assuming I haven't made any mistakes - do all of its
work without either control flow or memory addressing depending on the
data words of the input numbers. (Though, being an _arbitrary_
precision library, it does have to at least depend on the sizes of the
numbers - but there's a 'formal' size that can vary separately from
the actual magnitude of the represented integer, so if you want to
keep it secret that your number is actually small, it should work fine
to have a very long mp_int and just happen to store 23 in it.) So I've
done all my conditionalisation by means of computing both answers and
doing bit-masking to swap the right one into place, and all loops over
the words of an mp_int go up to the formal size rather than the actual
size.
I haven't actually tested the constant-time property in any rigorous
way yet (I'm still considering the best way to do it). But this code
is surely at the very least a big improvement on the old version, even
if I later find a few more things to fix.
I've also completely rewritten the low-level elliptic curve arithmetic
from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c
than it is to the SSH end of the code. The new elliptic curve code
keeps all coordinates in Montgomery-multiplication transformed form to
speed up all the multiplications mod the same prime, and only converts
them back when you ask for the affine coordinates. Also, I adopted
extended coordinates for the Edwards curve implementation.
sshecc.c has also had a near-total rewrite in the course of switching
it over to the new system. While I was there, I've separated ECDSA and
EdDSA more completely - they now have separate vtables, instead of a
single vtable in which nearly every function had a big if statement in
it - and also made the externally exposed types for an ECDSA key and
an ECDH context different.
A minor new feature: since the new arithmetic code includes a modular
square root function, we can now support the compressed point
representation for the NIST curves. We seem to have been getting along
fine without that so far, but it seemed a shame not to put it in,
since it was suddenly easy.
In sshrsa.c, one major change is that I've removed the RSA blinding
step in rsa_privkey_op, in which we randomise the ciphertext before
doing the decryption. The purpose of that was to avoid timing leaks
giving away the plaintext - but the new arithmetic code should take
that in its stride in the course of also being careful enough to avoid
leaking the _private key_, which RSA blinding had no way to do
anything about in any case.
Apart from those specific points, most of the rest of the changes are
more or less mechanical, just changing type names and translating code
into the new API.
2018-12-31 16:53:41 +03:00
|
|
|
ARITH = mpint ecc
|
New test system for mp_int and cryptography.
I've written a new standalone test program which incorporates all of
PuTTY's crypto code, including the mp_int and low-level elliptic curve
layers but also going all the way up to the implementations of the
MAC, hash, cipher, public key and kex abstractions.
The test program itself, 'testcrypt', speaks a simple line-oriented
protocol on standard I/O in which you write the name of a function
call followed by some inputs, and it gives you back a list of outputs
preceded by a line telling you how many there are. Dynamically
allocated objects are assigned string ids in the protocol, and there's
a 'free' function that tells testcrypt when it can dispose of one.
It's possible to speak that protocol by hand, but cumbersome. I've
also provided a Python module that wraps it, by running testcrypt as a
persistent subprocess and gatewaying all the function calls into
things that look reasonably natural to call from Python. The Python
module and testcrypt.c both read a carefully formatted header file
testcrypt.h which contains the name and signature of every exported
function, so it costs minimal effort to expose a given function
through this test API. In a few cases it's necessary to write a
wrapper in testcrypt.c that makes the function look more friendly, but
mostly you don't even need that. (Though that is one of the
motivations between a lot of API cleanups I've done recently!)
I considered doing Python integration in the more obvious way, by
linking parts of the PuTTY code directly into a native-code .so Python
module. I decided against it because this way is more flexible: I can
run the testcrypt program on its own, or compile it in a way that
Python wouldn't play nicely with (I bet compiling just that .so with
Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or
attach a debugger to it. I can even recompile testcrypt for a
different CPU architecture (32- vs 64-bit, or even running it on a
different machine over ssh or under emulation) and still layer the
nice API on top of that via the local Python interpreter. All I need
is a bidirectional data channel.
2019-01-01 22:08:37 +03:00
|
|
|
SSHCRYPTO = ARITH sshmd5 sshsha sshsh256 sshsh512
|
|
|
|
|
+ sshrsa sshdss sshecc
|
|
|
|
|
+ sshdes sshblowf sshaes sshccp ssharcf
|
2019-01-18 09:51:12 +03:00
|
|
|
+ sshdh sshcrc sshcrcda sshauxcrypt
|
New test system to detect side channels in crypto code.
All the work I've put in in the last few months to eliminate timing
and cache side channels from PuTTY's mp_int and cipher implementations
has been on a seat-of-the-pants basis: just thinking very hard about
what kinds of language construction I think would be safe to use, and
trying not to absentmindedly leave a conditional branch or a cast to
bool somewhere vital.
Now I've got a test suite! The basic idea is that you run the same
crypto primitive multiple times, with inputs differing only in ways
that are supposed to avoid being leaked by timing or leaving evidence
in the cache; then you instrument the code so that it logs all the
control flow, memory access and a couple of other relevant things in
each of those runs, and finally, compare the logs and expect them to
be identical.
The instrumentation is done using DynamoRIO, which I found to be well
suited to this kind of work: it lets you define custom modifications
of the code in a reasonably low-effort way, and it lets you work at
both the low level of examining single instructions _and_ the higher
level of the function call ABI (so you can give things like malloc
special treatment, not to mention intercepting communications from the
program being instrumented). Build instructions are all in the comment
at the top of testsc.c.
At present, I've found this test to give a 100% pass rate using gcc
-O0 and -O3 (Ubuntu 18.10). With clang, there are a couple of
failures, which I'll fix in the next commit.
2019-02-10 16:09:53 +03:00
|
|
|
+ sshhmac
|
|
|
|
|
SSHCOMMON = sshcommon sshprng sshrand SSHCRYPTO
|
Expose CRC32 to testcrypt, and add tests for it.
Finding even semi-official test vectors for this CRC implementation
was hard, because it turns out not to _quite_ match any of the well
known ones catalogued on the web. Its _polynomial_ is well known, but
the combination of details that go alongside it (starting state,
post-hashing transformation) are not quite the same as any other hash
I know of.
After trawling catalogue websites for a while I finally worked out
that SSH-1's CRC and RFC 1662's CRC are basically the same except for
different choices of starting value and final adjustment. And RFC
1662's CRC is common enough that there _are_ test vectors.
So I've renamed the previous crc32_compute function to crc32_ssh1,
reflecting that it seems to be its own thing unlike any other CRC;
implemented the RFC 1662 CRC as well, as an alternative tiny wrapper
on the inner crc32_update function; and exposed all three functions to
testcrypt. That lets me run standard test vectors _and_ directed tests
of the internal update routine, plus one check that crc32_ssh1 itself
does what I expect.
While I'm here, I've also modernised the code to use uint32_t in place
of unsigned long, and ptrlen instead of separate pointer,length
arguments. And I've removed the general primer on CRC theory from the
header comment, in favour of the more specifically useful information
about _which_ CRC this is and how it matches up to anything else out
there.
(I've bowed to inevitability and put the directed CRC tests in the
'crypt' class in cryptsuite.py. Of course this is a misnomer, since
CRC isn't cryptography, but it falls into the same category in terms
of the role it plays in SSH-1, and I didn't feel like making a new
pointedly-named 'notreallycrypt' container class just for this :-)
2019-01-14 23:45:19 +03:00
|
|
|
+ sshverstring
|
2019-01-15 00:19:38 +03:00
|
|
|
+ sshpubk sshzlib
|
New test system for mp_int and cryptography.
I've written a new standalone test program which incorporates all of
PuTTY's crypto code, including the mp_int and low-level elliptic curve
layers but also going all the way up to the implementations of the
MAC, hash, cipher, public key and kex abstractions.
The test program itself, 'testcrypt', speaks a simple line-oriented
protocol on standard I/O in which you write the name of a function
call followed by some inputs, and it gives you back a list of outputs
preceded by a line telling you how many there are. Dynamically
allocated objects are assigned string ids in the protocol, and there's
a 'free' function that tells testcrypt when it can dispose of one.
It's possible to speak that protocol by hand, but cumbersome. I've
also provided a Python module that wraps it, by running testcrypt as a
persistent subprocess and gatewaying all the function calls into
things that look reasonably natural to call from Python. The Python
module and testcrypt.c both read a carefully formatted header file
testcrypt.h which contains the name and signature of every exported
function, so it costs minimal effort to expose a given function
through this test API. In a few cases it's necessary to write a
wrapper in testcrypt.c that makes the function look more friendly, but
mostly you don't even need that. (Though that is one of the
motivations between a lot of API cleanups I've done recently!)
I considered doing Python integration in the more obvious way, by
linking parts of the PuTTY code directly into a native-code .so Python
module. I decided against it because this way is more flexible: I can
run the testcrypt program on its own, or compile it in a way that
Python wouldn't play nicely with (I bet compiling just that .so with
Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or
attach a debugger to it. I can even recompile testcrypt for a
different CPU architecture (32- vs 64-bit, or even running it on a
different machine over ssh or under emulation) and still layer the
nice API on top of that via the local Python interpreter. All I need
is a bidirectional data channel.
2019-01-01 22:08:37 +03:00
|
|
|
+ sshmac marshal nullplug
|
|
|
|
|
+ sshgssc pgssapi wildcard ssh1censor ssh2censor ssh2bpp
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
|
|
|
+ ssh2transport ssh2transhk ssh2connection portfwd x11fwd
|
|
|
|
|
+ ssh1connection ssh1bpp
|
|
|
|
|
SSH = SSHCOMMON ssh ssh2bpp-bare
|
|
|
|
|
+ ssh1login ssh2userauth
|
|
|
|
|
+ pinger
|
|
|
|
|
+ sshshare aqsync agentf
|
|
|
|
|
+ mainchan ssh2kex-client ssh2connection-client ssh1connection-client
|
2015-11-25 01:02:24 +03:00
|
|
|
WINSSH = SSH winnoise wincapi winpgntc wingss winshare winnps winnpc
|
2013-11-17 18:05:41 +04:00
|
|
|
+ winhsock errsock
|
|
|
|
|
UXSSH = SSH uxnoise uxagentc uxgss uxshare
|
2002-03-16 18:49:28 +03:00
|
|
|
|
|
|
|
|
# SFTP implementation (pscp, psftp).
|
2019-02-20 10:09:10 +03:00
|
|
|
SFTP = sftp sftpcommon logging cmdline stripctrl
|
2002-03-16 18:49:28 +03:00
|
|
|
|
2018-05-24 11:17:13 +03:00
|
|
|
# Miscellaneous objects appearing in all the utilities, or all the
|
|
|
|
|
# network ones, or the Unix or Windows subsets of those in turn.
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
MISC = misc utils marshal memory
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
|
|
|
MISCNETCOMMON = timing callback MISC version tree234 CONF
|
|
|
|
|
MISCNET = MISCNETCOMMON be_misc settings proxy
|
2018-05-24 11:17:13 +03:00
|
|
|
WINMISC = MISCNET winstore winnet winhandl cmdline windefs winmisc winproxy
|
2019-01-11 09:39:52 +03:00
|
|
|
+ wintime winhsock errsock winsecur winucs miscucs winmiscs
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
|
|
|
UXMISCCOMMON = MISCNETCOMMON uxstore uxsel uxnet uxpeer uxmisc time
|
|
|
|
|
+ uxfdsock errsock
|
2019-01-17 01:08:45 +03:00
|
|
|
UXMISC = MISCNET UXMISCCOMMON uxproxy uxutils
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
|
|
|
|
|
|
|
|
# SSH server.
|
|
|
|
|
SSHSERVER = SSHCOMMON sshserver settings be_none logging ssh2kex-server
|
|
|
|
|
+ ssh2userauth-server sshrsag sshprime ssh2connection-server
|
2018-10-27 01:08:58 +03:00
|
|
|
+ sesschan sftpcommon sftpserver proxy cproxy ssh1login-server
|
2018-10-20 13:19:17 +03:00
|
|
|
+ ssh1connection-server scpserver
|
2002-03-16 18:49:28 +03:00
|
|
|
|
2015-04-27 22:48:29 +03:00
|
|
|
# import.c and dependencies, for PuTTYgen-like utilities that have to
|
|
|
|
|
# load foreign key files.
|
2018-05-24 15:11:56 +03:00
|
|
|
IMPORT = import sshbcrypt sshblowf marshal
|
2015-04-27 22:48:29 +03:00
|
|
|
|
2002-12-31 15:20:34 +03:00
|
|
|
# Character set library, for use in pterm.
|
2003-04-05 20:36:11 +04:00
|
|
|
CHARSET = sbcsdat slookup sbcs utf8 toucs fromucs xenc mimeenc macenc localenc
|
2002-12-31 15:20:34 +03:00
|
|
|
|
2003-10-12 17:46:12 +04:00
|
|
|
# Standard libraries.
|
2017-03-14 00:42:44 +03:00
|
|
|
LIBS = advapi32.lib user32.lib gdi32.lib comdlg32.lib
|
2017-03-14 00:28:36 +03:00
|
|
|
+ shell32.lib imm32.lib ole32.lib
|
2002-03-16 18:49:28 +03:00
|
|
|
|
2004-08-30 17:11:17 +04:00
|
|
|
# Network backend sets. This also brings in the relevant attachment
|
|
|
|
|
# to proxy.c depending on whether we're crypto-avoidant or not.
|
|
|
|
|
BE_ALL = be_all cproxy
|
|
|
|
|
BE_NOSSH = be_nossh nocproxy
|
2011-07-27 22:43:16 +04:00
|
|
|
BE_SSH = be_ssh cproxy
|
2004-08-30 17:11:17 +04:00
|
|
|
BE_NONE = be_none nocproxy
|
2006-08-28 14:35:12 +04:00
|
|
|
# More backend sets, with the additional Windows serial-port module.
|
|
|
|
|
W_BE_ALL = be_all_s winser cproxy
|
|
|
|
|
W_BE_NOSSH = be_nos_s winser nocproxy
|
2006-08-28 18:29:02 +04:00
|
|
|
# And with the Unix serial-port module.
|
|
|
|
|
U_BE_ALL = be_all_s uxser cproxy
|
|
|
|
|
U_BE_NOSSH = be_nos_s uxser nocproxy
|
2004-08-30 17:11:17 +04:00
|
|
|
|
2004-04-25 13:04:38 +04:00
|
|
|
# ------------------------------------------------------------
|
2002-03-16 18:49:28 +03:00
|
|
|
# Definitions of actual programs. The program name, followed by a
|
|
|
|
|
# colon, followed by a list of objects. Also in the list may be the
|
2002-10-07 20:45:23 +04:00
|
|
|
# keywords [G] for Windows GUI app, [C] for Console app, [X] for
|
2010-09-25 12:37:30 +04:00
|
|
|
# X/GTK Unix app, [U] for command-line Unix app.
|
2002-03-16 18:49:28 +03:00
|
|
|
|
2008-11-17 21:38:09 +03:00
|
|
|
putty : [G] GUITERM NONSSH WINSSH W_BE_ALL WINMISC winx11 putty.res LIBS
|
2010-05-19 22:22:17 +04:00
|
|
|
puttytel : [G] GUITERM NONSSH W_BE_NOSSH WINMISC puttytel.res nogss LIBS
|
2006-08-28 14:35:12 +04:00
|
|
|
plink : [C] winplink wincons NONSSH WINSSH W_BE_ALL logging WINMISC
|
Plink: default to sanitising non-tty console output.
If Plink's standard output and/or standard error points at a Windows
console or a Unix tty device, and if Plink was not configured to
request a remote pty (and hence to send a terminal-type string), then
we apply the new control-character stripping facility.
The idea is to be a mild defence against malicious remote processes
sending confusing escape sequences through the standard error channel
when Plink is being used as a transport for something like git: it's
OK to have actual sensible error messages come back from the server,
but when you run a git command, you didn't really intend to give the
remote server the implicit licence to write _all over_ your local
terminal display. At the same time, in that scenario, the standard
_output_ of Plink is left completely alone, on the grounds that git
will be expecting it to be 8-bit clean. (And Plink can tell that
because it's redirected away from the console.)
For interactive login sessions using Plink, this behaviour is
disabled, on the grounds that once you've sent a terminal-type string
it's assumed that you were _expecting_ the server to use it to know
what escape sequences to send to you.
So it should be transparent for all the use cases I've so far thought
of. But in case it's not, there's a family of new command-line options
like -no-sanitise-stdout and -sanitise-stderr that you can use to
forcibly override the autodetection of whether to do it.
This all applies the same way to both Unix and Windows Plink.
2019-02-20 10:03:57 +03:00
|
|
|
+ winx11 plink.res winnojmp sessprep stripctrl noterm LIBS
|
2004-12-16 18:01:43 +03:00
|
|
|
pscp : [C] pscp winsftp wincons WINSSH BE_SSH SFTP wildcard WINMISC
|
2010-12-23 20:32:28 +03:00
|
|
|
+ pscp.res winnojmp LIBS
|
2005-02-28 03:17:09 +03:00
|
|
|
psftp : [C] psftp winsftp wincons WINSSH BE_SSH SFTP wildcard WINMISC
|
2010-12-23 20:32:28 +03:00
|
|
|
+ psftp.res winnojmp LIBS
|
2002-03-16 18:49:28 +03:00
|
|
|
|
Complete rewrite of PuTTY's bignum library.
The old 'Bignum' data type is gone completely, and so is sshbn.c. In
its place is a new thing called 'mp_int', handled by an entirely new
library module mpint.c, with API differences both large and small.
The main aim of this change is that the new library should be free of
timing- and cache-related side channels. I've written the code so that
it _should_ - assuming I haven't made any mistakes - do all of its
work without either control flow or memory addressing depending on the
data words of the input numbers. (Though, being an _arbitrary_
precision library, it does have to at least depend on the sizes of the
numbers - but there's a 'formal' size that can vary separately from
the actual magnitude of the represented integer, so if you want to
keep it secret that your number is actually small, it should work fine
to have a very long mp_int and just happen to store 23 in it.) So I've
done all my conditionalisation by means of computing both answers and
doing bit-masking to swap the right one into place, and all loops over
the words of an mp_int go up to the formal size rather than the actual
size.
I haven't actually tested the constant-time property in any rigorous
way yet (I'm still considering the best way to do it). But this code
is surely at the very least a big improvement on the old version, even
if I later find a few more things to fix.
I've also completely rewritten the low-level elliptic curve arithmetic
from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c
than it is to the SSH end of the code. The new elliptic curve code
keeps all coordinates in Montgomery-multiplication transformed form to
speed up all the multiplications mod the same prime, and only converts
them back when you ask for the affine coordinates. Also, I adopted
extended coordinates for the Edwards curve implementation.
sshecc.c has also had a near-total rewrite in the course of switching
it over to the new system. While I was there, I've separated ECDSA and
EdDSA more completely - they now have separate vtables, instead of a
single vtable in which nearly every function had a big if statement in
it - and also made the externally exposed types for an ECDSA key and
an ECDH context different.
A minor new feature: since the new arithmetic code includes a modular
square root function, we can now support the compressed point
representation for the NIST curves. We seem to have been getting along
fine without that so far, but it seemed a shame not to put it in,
since it was suddenly easy.
In sshrsa.c, one major change is that I've removed the RSA blinding
step in rsa_privkey_op, in which we randomise the ciphertext before
doing the decryption. The purpose of that was to avoid timing leaks
giving away the plaintext - but the new arithmetic code should take
that in its stride in the course of also being careful enough to avoid
leaking the _private key_, which RSA blinding had no way to do
anything about in any case.
Apart from those specific points, most of the rest of the changes are
more or less mechanical, just changing type names and translating code
into the new API.
2018-12-31 16:53:41 +03:00
|
|
|
pageant : [G] winpgnt pageant sshrsa sshpubk sshdes ARITH sshmd5 version
|
2018-05-24 11:17:13 +03:00
|
|
|
+ tree234 MISC sshaes sshsha winsecur winpgntc aqsync sshdss sshsh256
|
2019-01-11 09:39:52 +03:00
|
|
|
+ sshsh512 winutils sshecc winmisc winmiscs winhelp conf pageant.res
|
2019-01-20 19:18:49 +03:00
|
|
|
+ sshauxcrypt sshhmac LIBS
|
2002-03-16 18:49:28 +03:00
|
|
|
|
Complete rewrite of PuTTY's bignum library.
The old 'Bignum' data type is gone completely, and so is sshbn.c. In
its place is a new thing called 'mp_int', handled by an entirely new
library module mpint.c, with API differences both large and small.
The main aim of this change is that the new library should be free of
timing- and cache-related side channels. I've written the code so that
it _should_ - assuming I haven't made any mistakes - do all of its
work without either control flow or memory addressing depending on the
data words of the input numbers. (Though, being an _arbitrary_
precision library, it does have to at least depend on the sizes of the
numbers - but there's a 'formal' size that can vary separately from
the actual magnitude of the represented integer, so if you want to
keep it secret that your number is actually small, it should work fine
to have a very long mp_int and just happen to store 23 in it.) So I've
done all my conditionalisation by means of computing both answers and
doing bit-masking to swap the right one into place, and all loops over
the words of an mp_int go up to the formal size rather than the actual
size.
I haven't actually tested the constant-time property in any rigorous
way yet (I'm still considering the best way to do it). But this code
is surely at the very least a big improvement on the old version, even
if I later find a few more things to fix.
I've also completely rewritten the low-level elliptic curve arithmetic
from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c
than it is to the SSH end of the code. The new elliptic curve code
keeps all coordinates in Montgomery-multiplication transformed form to
speed up all the multiplications mod the same prime, and only converts
them back when you ask for the affine coordinates. Also, I adopted
extended coordinates for the Edwards curve implementation.
sshecc.c has also had a near-total rewrite in the course of switching
it over to the new system. While I was there, I've separated ECDSA and
EdDSA more completely - they now have separate vtables, instead of a
single vtable in which nearly every function had a big if statement in
it - and also made the externally exposed types for an ECDSA key and
an ECDH context different.
A minor new feature: since the new arithmetic code includes a modular
square root function, we can now support the compressed point
representation for the NIST curves. We seem to have been getting along
fine without that so far, but it seemed a shame not to put it in,
since it was suddenly easy.
In sshrsa.c, one major change is that I've removed the RSA blinding
step in rsa_privkey_op, in which we randomise the ciphertext before
doing the decryption. The purpose of that was to avoid timing leaks
giving away the plaintext - but the new arithmetic code should take
that in its stride in the course of also being careful enough to avoid
leaking the _private key_, which RSA blinding had no way to do
anything about in any case.
Apart from those specific points, most of the rest of the changes are
more or less mechanical, just changing type names and translating code
into the new API.
2018-12-31 16:53:41 +03:00
|
|
|
puttygen : [G] winpgen sshrsag sshdssg sshprime sshdes ARITH sshmd5 version
|
2018-05-24 11:17:13 +03:00
|
|
|
+ sshrand winnoise sshsha winstore MISC winctrls sshrsa sshdss winmisc
|
2015-04-27 22:48:29 +03:00
|
|
|
+ sshpubk sshaes sshsh256 sshsh512 IMPORT winutils puttygen.res
|
Replace PuTTY's PRNG with a Fortuna-like system.
This tears out the entire previous random-pool system in sshrand.c. In
its place is a system pretty close to Ferguson and Schneier's
'Fortuna' generator, with the main difference being that I use SHA-256
instead of AES for the generation side of the system (rationale given
in comment).
The PRNG implementation lives in sshprng.c, and defines a self-
contained data type with no state stored outside the object, so you
can instantiate however many of them you like. The old sshrand.c still
exists, but in place of the previous random pool system, it's just
become a client of sshprng.c, whose job is to hold a single global
instance of the PRNG type, and manage its reference count, save file,
noise-collection timers and similar administrative business.
Advantages of this change include:
- Fortuna is designed with a more varied threat model in mind than my
old home-grown random pool. For example, after any request for
random numbers, it automatically re-seeds itself, so that if the
state of the PRNG should be leaked, it won't give enough
information to find out what past outputs _were_.
- The PRNG type can be instantiated with any hash function; the
instance used by the main tools is based on SHA-256, an improvement
on the old pool's use of SHA-1.
- The new PRNG only uses the completely standard interface to the
hash function API, instead of having to have privileged access to
the internal SHA-1 block transform function. This will make it
easier to revamp the hash code in general, and also it means that
hardware-accelerated versions of SHA-256 will automatically be used
for the PRNG as well as for everything else.
- The new PRNG can be _tested_! Because it has an actual (if not
quite explicit) specification for exactly what the output numbers
_ought_ to be derived from the hashes of, I can (and have) put
tests in cryptsuite that ensure the output really is being derived
in the way I think it is. The old pool could have been returning
any old nonsense and it would have been very hard to tell for sure.
2019-01-23 01:42:41 +03:00
|
|
|
+ tree234 notiming winhelp winnojmp CONF LIBS wintime sshecc sshprng
|
2019-01-20 19:18:49 +03:00
|
|
|
+ sshecdsag sshauxcrypt sshhmac winsecur winmiscs
|
2002-10-07 20:45:23 +04:00
|
|
|
|
2005-02-16 00:45:50 +03:00
|
|
|
pterm : [X] GTKTERM uxmisc misc ldisc settings uxpty uxsel BE_NONE uxstore
|
2007-01-06 23:01:30 +03:00
|
|
|
+ uxsignal CHARSET cmdline uxpterm version time xpmpterm xpmptcfg
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
+ nogss utils memory GTKMAIN
|
2006-08-28 18:29:02 +04:00
|
|
|
putty : [X] GTKTERM uxmisc misc ldisc settings uxsel U_BE_ALL uxstore
|
2007-01-06 23:01:30 +03:00
|
|
|
+ uxsignal CHARSET uxputty NONSSH UXSSH UXMISC ux_x11 xpmputty
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
+ xpmpucfg utils memory GTKMAIN
|
2006-08-28 18:29:02 +04:00
|
|
|
puttytel : [X] GTKTERM uxmisc misc ldisc settings uxsel U_BE_NOSSH
|
2007-01-06 23:01:30 +03:00
|
|
|
+ uxstore uxsignal CHARSET uxputty NONSSH UXMISC xpmputty xpmpucfg
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
+ nogss utils memory GTKMAIN
|
2002-10-31 22:49:52 +03:00
|
|
|
|
2006-08-28 18:29:02 +04:00
|
|
|
plink : [U] uxplink uxcons NONSSH UXSSH U_BE_ALL logging UXMISC uxsignal
|
Plink: default to sanitising non-tty console output.
If Plink's standard output and/or standard error points at a Windows
console or a Unix tty device, and if Plink was not configured to
request a remote pty (and hence to send a terminal-type string), then
we apply the new control-character stripping facility.
The idea is to be a mild defence against malicious remote processes
sending confusing escape sequences through the standard error channel
when Plink is being used as a transport for something like git: it's
OK to have actual sensible error messages come back from the server,
but when you run a git command, you didn't really intend to give the
remote server the implicit licence to write _all over_ your local
terminal display. At the same time, in that scenario, the standard
_output_ of Plink is left completely alone, on the grounds that git
will be expecting it to be 8-bit clean. (And Plink can tell that
because it's redirected away from the console.)
For interactive login sessions using Plink, this behaviour is
disabled, on the grounds that once you've sent a terminal-type string
it's assumed that you were _expecting_ the server to use it to know
what escape sequences to send to you.
So it should be transparent for all the use cases I've so far thought
of. But in case it's not, there's a family of new command-line options
like -no-sanitise-stdout and -sanitise-stderr that you can use to
forcibly override the autodetection of whether to do it.
This all applies the same way to both Unix and Windows Plink.
2019-02-20 10:03:57 +03:00
|
|
|
+ ux_x11 noterm uxnogtk sessprep cmdline stripctrl
|
2002-12-03 00:03:14 +03:00
|
|
|
|
Replace PuTTY's PRNG with a Fortuna-like system.
This tears out the entire previous random-pool system in sshrand.c. In
its place is a system pretty close to Ferguson and Schneier's
'Fortuna' generator, with the main difference being that I use SHA-256
instead of AES for the generation side of the system (rationale given
in comment).
The PRNG implementation lives in sshprng.c, and defines a self-
contained data type with no state stored outside the object, so you
can instantiate however many of them you like. The old sshrand.c still
exists, but in place of the previous random pool system, it's just
become a client of sshprng.c, whose job is to hold a single global
instance of the PRNG type, and manage its reference count, save file,
noise-collection timers and similar administrative business.
Advantages of this change include:
- Fortuna is designed with a more varied threat model in mind than my
old home-grown random pool. For example, after any request for
random numbers, it automatically re-seeds itself, so that if the
state of the PRNG should be leaked, it won't give enough
information to find out what past outputs _were_.
- The PRNG type can be instantiated with any hash function; the
instance used by the main tools is based on SHA-256, an improvement
on the old pool's use of SHA-1.
- The new PRNG only uses the completely standard interface to the
hash function API, instead of having to have privileged access to
the internal SHA-1 block transform function. This will make it
easier to revamp the hash code in general, and also it means that
hardware-accelerated versions of SHA-256 will automatically be used
for the PRNG as well as for everything else.
- The new PRNG can be _tested_! Because it has an actual (if not
quite explicit) specification for exactly what the output numbers
_ought_ to be derived from the hashes of, I can (and have) put
tests in cryptsuite that ensure the output really is being derived
in the way I think it is. The old pool could have been returning
any old nonsense and it would have been very hard to tell for sure.
2019-01-23 01:42:41 +03:00
|
|
|
PUTTYGEN_UNIX = sshrsag sshdssg sshprime sshdes ARITH sshmd5 version sshprng
|
2018-05-24 11:17:13 +03:00
|
|
|
+ sshrand uxnoise sshsha MISC sshrsa sshdss uxcons uxstore uxmisc
|
2015-04-27 22:48:29 +03:00
|
|
|
+ sshpubk sshaes sshsh256 sshsh512 IMPORT puttygen.res time tree234
|
2019-01-20 19:18:49 +03:00
|
|
|
+ uxgen notiming CONF sshecc sshecdsag uxnogtk sshauxcrypt sshhmac
|
2016-03-30 10:25:25 +03:00
|
|
|
puttygen : [U] cmdgen PUTTYGEN_UNIX
|
|
|
|
|
cgtest : [UT] cgtest PUTTYGEN_UNIX
|
2004-01-22 22:15:32 +03:00
|
|
|
|
2017-02-15 22:29:05 +03:00
|
|
|
pscp : [U] pscp uxsftp uxcons UXSSH BE_SSH SFTP wildcard UXMISC uxnogtk
|
|
|
|
|
psftp : [U] psftp uxsftp uxcons UXSSH BE_SSH SFTP wildcard UXMISC uxnogtk
|
2003-08-24 16:47:46 +04:00
|
|
|
|
Complete rewrite of PuTTY's bignum library.
The old 'Bignum' data type is gone completely, and so is sshbn.c. In
its place is a new thing called 'mp_int', handled by an entirely new
library module mpint.c, with API differences both large and small.
The main aim of this change is that the new library should be free of
timing- and cache-related side channels. I've written the code so that
it _should_ - assuming I haven't made any mistakes - do all of its
work without either control flow or memory addressing depending on the
data words of the input numbers. (Though, being an _arbitrary_
precision library, it does have to at least depend on the sizes of the
numbers - but there's a 'formal' size that can vary separately from
the actual magnitude of the represented integer, so if you want to
keep it secret that your number is actually small, it should work fine
to have a very long mp_int and just happen to store 23 in it.) So I've
done all my conditionalisation by means of computing both answers and
doing bit-masking to swap the right one into place, and all loops over
the words of an mp_int go up to the formal size rather than the actual
size.
I haven't actually tested the constant-time property in any rigorous
way yet (I'm still considering the best way to do it). But this code
is surely at the very least a big improvement on the old version, even
if I later find a few more things to fix.
I've also completely rewritten the low-level elliptic curve arithmetic
from sshecc.c; the new ecc.c is closer to being an adjunct of mpint.c
than it is to the SSH end of the code. The new elliptic curve code
keeps all coordinates in Montgomery-multiplication transformed form to
speed up all the multiplications mod the same prime, and only converts
them back when you ask for the affine coordinates. Also, I adopted
extended coordinates for the Edwards curve implementation.
sshecc.c has also had a near-total rewrite in the course of switching
it over to the new system. While I was there, I've separated ECDSA and
EdDSA more completely - they now have separate vtables, instead of a
single vtable in which nearly every function had a big if statement in
it - and also made the externally exposed types for an ECDSA key and
an ECDH context different.
A minor new feature: since the new arithmetic code includes a modular
square root function, we can now support the compressed point
representation for the NIST curves. We seem to have been getting along
fine without that so far, but it seemed a shame not to put it in,
since it was suddenly easy.
In sshrsa.c, one major change is that I've removed the RSA blinding
step in rsa_privkey_op, in which we randomise the ciphertext before
doing the decryption. The purpose of that was to avoid timing leaks
giving away the plaintext - but the new arithmetic code should take
that in its stride in the course of also being careful enough to avoid
leaking the _private key_, which RSA blinding had no way to do
anything about in any case.
Apart from those specific points, most of the rest of the changes are
more or less mechanical, just changing type names and translating code
into the new API.
2018-12-31 16:53:41 +03:00
|
|
|
pageant : [X] uxpgnt uxagentc aqsync pageant sshrsa sshpubk sshdes ARITH
|
2017-01-29 23:24:15 +03:00
|
|
|
+ sshmd5 version tree234 misc sshaes sshsha sshdss sshsh256 sshsh512
|
2018-05-24 12:48:20 +03:00
|
|
|
+ sshecc CONF uxsignal nocproxy nogss be_none x11fwd ux_x11 uxcons
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
+ gtkask gtkmisc nullplug logging UXMISC uxagentsock utils memory
|
2019-01-20 19:18:49 +03:00
|
|
|
+ sshauxcrypt sshhmac
|
2015-05-05 22:16:23 +03:00
|
|
|
|
2016-03-24 01:22:30 +03:00
|
|
|
ptermapp : [XT] GTKTERM uxmisc misc ldisc settings uxpty uxsel BE_NONE uxstore
|
2017-11-27 22:38:02 +03:00
|
|
|
+ uxsignal CHARSET uxpterm version time xpmpterm xpmptcfg
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
+ nogss gtkapp nocmdline utils memory
|
2016-03-24 01:22:30 +03:00
|
|
|
puttyapp : [XT] GTKTERM uxmisc misc ldisc settings uxsel U_BE_ALL uxstore
|
|
|
|
|
+ uxsignal CHARSET uxputty NONSSH UXSSH UXMISC ux_x11 xpmputty
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
+ xpmpucfg gtkapp nocmdline utils memory
|
2016-03-24 01:13:30 +03:00
|
|
|
osxlaunch : [UT] osxlaunch
|
|
|
|
|
|
Move standalone parts of misc.c into utils.c.
misc.c has always contained a combination of things that are tied
tightly into the PuTTY code base (e.g. they use the conf system, or
work with our sockets abstraction) and things that are pure standalone
utility functions like nullstrcmp() which could quite happily be
dropped into any C program without causing a link failure.
Now the latter kind of standalone utility code lives in the new source
file utils.c, whose only external dependency is on memory.c (for snew,
sfree etc), which in turn requires the user to provide an
out_of_memory() function. So it should now be much easier to link test
programs that use PuTTY's low-level functions without also pulling in
half its bulky infrastructure.
In the process, I came across a memory allocation logging system
enabled by -DMALLOC_LOG that looks long since bit-rotted; in any case
we have much more advanced tools for that kind of thing these days,
like valgrind and Leak Sanitiser, so I've just removed it rather than
trying to transplant it somewhere sensible. (We can always pull it
back out of the version control history if really necessary, but I
haven't used it in at least a decade.)
The other slightly silly thing I did was to give bufchain a function
pointer field that points to queue_idempotent_callback(), and disallow
direct setting of the 'ic' field in favour of calling
bufchain_set_callback which will fill that pointer in too. That allows
the bufchain system to live in utils.c rather than misc.c, so that
programs can use it without also having to link in the callback system
or provide an annoying stub of that function. In fact that's just
allowed me to remove stubs of that kind from PuTTYgen and Pageant!
2019-01-03 11:44:11 +03:00
|
|
|
fuzzterm : [UT] UXTERM CHARSET MISC version uxmisc uxucs fuzzterm time settings
|
2018-11-27 22:20:32 +03:00
|
|
|
+ uxstore be_none uxnogtk memory
|
New test system to detect side channels in crypto code.
All the work I've put in in the last few months to eliminate timing
and cache side channels from PuTTY's mp_int and cipher implementations
has been on a seat-of-the-pants basis: just thinking very hard about
what kinds of language construction I think would be safe to use, and
trying not to absentmindedly leave a conditional branch or a cast to
bool somewhere vital.
Now I've got a test suite! The basic idea is that you run the same
crypto primitive multiple times, with inputs differing only in ways
that are supposed to avoid being leaked by timing or leaving evidence
in the cache; then you instrument the code so that it logs all the
control flow, memory access and a couple of other relevant things in
each of those runs, and finally, compare the logs and expect them to
be identical.
The instrumentation is done using DynamoRIO, which I found to be well
suited to this kind of work: it lets you define custom modifications
of the code in a reasonably low-effort way, and it lets you work at
both the low level of examining single instructions _and_ the higher
level of the function call ABI (so you can give things like malloc
special treatment, not to mention intercepting communications from the
program being instrumented). Build instructions are all in the comment
at the top of testsc.c.
At present, I've found this test to give a 100% pass rate using gcc
-O0 and -O3 (Ubuntu 18.10). With clang, there are a couple of
failures, which I'll fix in the next commit.
2019-02-10 16:09:53 +03:00
|
|
|
testcrypt : [UT] testcrypt SSHCRYPTO sshprng sshprime marshal utils
|
|
|
|
|
+ memory tree234 uxutils
|
|
|
|
|
testcrypt : [C] testcrypt SSHCRYPTO sshprng sshprime marshal utils
|
|
|
|
|
+ memory tree234 winmiscs
|
|
|
|
|
testsc : [UT] testsc SSHCRYPTO marshal utils memory tree234 wildcard
|
|
|
|
|
+ sshmac uxutils
|
2018-11-27 22:22:15 +03:00
|
|
|
testzlib : [UT] testzlib sshzlib memory
|
2015-12-16 17:40:00 +03:00
|
|
|
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
|
|
|
uppity : [UT] uxserver SSHSERVER UXMISC uxsignal uxnoise uxgss uxnogtk
|
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 00:10:32 +03:00
|
|
|
+ uxpty uxsftpserver ux_x11 uxagentsock
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-21 00:09:54 +03:00
|
|
|
|
2015-12-16 17:40:00 +03:00
|
|
|
# ----------------------------------------------------------------------
|
|
|
|
|
# On Windows, provide a means of removing local test binaries that we
|
|
|
|
|
# aren't going to actually ship. (I prefer this to not building them
|
|
|
|
|
# in the first place, so that we find out about build breakage early.)
|
|
|
|
|
!begin vc
|
|
|
|
|
cleantestprogs:
|
Build testcrypt on Windows.
The bulk of this commit is the changes necessary to make testcrypt
compile under Visual Studio. Unfortunately, I've had to remove my
fiddly clever uses of C99 variadic macros, because Visual Studio does
something unexpected when a variadic macro's expansion puts
__VA_ARGS__ in the argument list of a further macro invocation: the
commas don't separate further arguments. In other words, if you write
#define INNER(x,y,z) some expansion involving x, y and z
#define OUTER(...) INNER(__VA_ARGS__)
OUTER(1,2,3)
then gcc and clang will translate OUTER(1,2,3) into INNER(1,2,3) in
the obvious way, and the inner macro will be expanded with x=1, y=2
and z=3. But try this in Visual Studio, and you'll get the macro
parameter x expanding to the entire string 1,2,3 and the other two
empty (with warnings complaining that INNER didn't get the number of
arguments it expected).
It's hard to cite chapter and verse of the standard to say which of
those is _definitely_ right, though my reading leans towards the
gcc/clang behaviour. But I do know I can't depend on it in code that
has to compile under both!
So I've removed the system that allowed me to declare everything in
testcrypt.h as FUNC(ret,fn,arg,arg,arg), and now I have to use a
different macro for each arity (FUNC0, FUNC1, FUNC2 etc). Also, the
WRAPPED_NAME system is gone (because that too depended on the use of a
comma to shift macro arguments along by one), and now I put a custom C
wrapper around a function by simply re-#defining that function's own
name (and therefore the subsequent code has to be a little more
careful to _not_ pass functions' names between several macros before
stringifying them).
That's all a bit tedious, and commits me to a small amount of ongoing
annoyance because now I'll have to add an explicit argument count
every time I add something to testcrypt.h. But then again, perhaps it
will make the code less incomprehensible to someone trying to
understand it!
2019-01-11 09:25:28 +03:00
|
|
|
-del $(BUILDDIR)testcrypt.exe
|
2015-12-16 17:40:00 +03:00
|
|
|
!end
|
2017-02-05 13:59:08 +03:00
|
|
|
!begin clangcl
|
|
|
|
|
cleantestprogs:
|
Build testcrypt on Windows.
The bulk of this commit is the changes necessary to make testcrypt
compile under Visual Studio. Unfortunately, I've had to remove my
fiddly clever uses of C99 variadic macros, because Visual Studio does
something unexpected when a variadic macro's expansion puts
__VA_ARGS__ in the argument list of a further macro invocation: the
commas don't separate further arguments. In other words, if you write
#define INNER(x,y,z) some expansion involving x, y and z
#define OUTER(...) INNER(__VA_ARGS__)
OUTER(1,2,3)
then gcc and clang will translate OUTER(1,2,3) into INNER(1,2,3) in
the obvious way, and the inner macro will be expanded with x=1, y=2
and z=3. But try this in Visual Studio, and you'll get the macro
parameter x expanding to the entire string 1,2,3 and the other two
empty (with warnings complaining that INNER didn't get the number of
arguments it expected).
It's hard to cite chapter and verse of the standard to say which of
those is _definitely_ right, though my reading leans towards the
gcc/clang behaviour. But I do know I can't depend on it in code that
has to compile under both!
So I've removed the system that allowed me to declare everything in
testcrypt.h as FUNC(ret,fn,arg,arg,arg), and now I have to use a
different macro for each arity (FUNC0, FUNC1, FUNC2 etc). Also, the
WRAPPED_NAME system is gone (because that too depended on the use of a
comma to shift macro arguments along by one), and now I put a custom C
wrapper around a function by simply re-#defining that function's own
name (and therefore the subsequent code has to be a little more
careful to _not_ pass functions' names between several macros before
stringifying them).
That's all a bit tedious, and commits me to a small amount of ongoing
annoyance because now I'll have to add an explicit argument count
every time I add something to testcrypt.h. But then again, perhaps it
will make the code less incomprehensible to someone trying to
understand it!
2019-01-11 09:25:28 +03:00
|
|
|
-rm -f $(BUILDDIR)testcrypt.exe
|
2017-02-05 13:59:08 +03:00
|
|
|
!end
|
