putty/Recipe

395 строки
16 KiB
Plaintext
Исходник Обычный вид История

# -*- 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.
# ------------------------------------------------------------
# Top-level configuration.
# Overall project name.
!name putty
# Locations and types of output Makefiles.
!makefile clangcl windows/Makefile.clangcl
!makefile vc windows/Makefile.vc
!makefile vcproj windows/MSVC
!makefile cygwin windows/Makefile.mgw
!makefile lcc windows/Makefile.lcc
!makefile gtk unix/Makefile.gtk
!makefile unix unix/Makefile.ux
Move the Unix configure script up to the top level. Previously, 'configure' and its assorted machinery lived in the 'unix' subdir, because that seemed like a clean place to keep it given that all the other per-platform Makefiles live in their platform directories. However, this never sat all that happily with autotools, and even less so now that it likes to have object file pathnames parallel source file pathnames: if you have Makefile.am refer to source files outside its subdir as "../terminal.c" and enable subdir-objects then any out-of-tree build calls the corresponding object file "../terminal.o" and so your build products mostly end up at the directory above your build dir! And as of autotools 1.14 my previous compensatory bodge of prefixing every source file path in Makefile.am with "$(srcdir)" has stopped working too. So I'm giving in to necessity, and changing policy by moving the configure machinery up to the top level of the source tree where autotools will be less confused by it. This should not be taken as any indication of the primacy of the Unix port, only of the recalcitrance of autotools. Whereas before we had a trivial script called 'configure' at the top level that invoked unix/configure to effectively do an 'out-of-tree build' (for make purposes) at the top level of the source tree, we now have a similar script in unix/configure. So this _should_ make very little difference: people who were previously running configure from the top level should still be able to, and likewise people who were running it from the unix subdir. [originally from svn r10141]
2014-02-22 22:01:32 +04:00
!makefile am Makefile.am
!makefile devcppproj windows/DEVCPP
!makefile vstudio10 windows/VS2010
!makefile vstudio12 windows/VS2012
# Source directories.
!srcdir charset/
!srcdir windows/
!srcdir unix/
# 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:
#
# - COMPAT=/DAUTO_WINSOCK (Windows only)
# Causes PuTTY to assume that <windows.h> includes its own WinSock
# header file, so that it won't try to include <winsock.h>.
#
# - COMPAT=/DWINSOCK_TWO (Windows only)
# Causes the PuTTY utilities to include <winsock2.h> instead of
# <winsock.h>, except Plink which _needs_ WinSock 2 so it already
# does this.
#
# - 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.
# - There is no support for restriction of the process ACLs.
#
# - COMPAT=/DNO_MULTIMON (Windows only)
# 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.
#
# - 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.
#
# If you don't have this header, you may be able to use the copy
# supplied with HTML Help Workshop.
#
# - RCFL=/DNO_MANIFESTS (Windows only)
# 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.
#
# - 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.
#
# - COMPAT=/DNO_GSSAPI
# Disables PuTTY's ability to use GSSAPI functions for
# authentication and key exchange.
#
# - COMPAT=/DSTATIC_GSSAPI
# Causes PuTTY to try to link statically against the GSSAPI
# library instead of the default of doing it at run time.
#
# - COMPAT=/DMSVC4 (Windows only)
# - RCFL=/DMSVC4
# Makes a couple of minor changes so that PuTTY compiles using
# MSVC 4. You will also need /DNO_SECURITY and /DNO_MULTIMON.
#
# - COMPAT=/DNO_SECUREZEROMEMORY (Windows only)
# Disables PuTTY's use of SecureZeroMemory(), which is missing
# from some environments' header files.
#
# - 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.
#
# - 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.
#
# - XFLAGS=/DMINEFIELD (Windows only)
# 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.
#
# - 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.
!end
# ------------------------------------------------------------
# Additional text added verbatim to each individual Makefile.
!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
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
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 */' >$@
endif
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
!begin vc vars
CFLAGS = $(CFLAGS) /DHAS_GSSAPI
!end
!begin clangcl vars
CFLAGS += /DHAS_GSSAPI
!end
# `make install' target for Unix.
!begin gtk
install:
mkdir -p $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir)
$(INSTALL_PROGRAM) -m 755 pageant $(DESTDIR)$(bindir)/pageant
$(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
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
$(INSTALL_PROGRAM) -m 755 putty $(DESTDIR)$(bindir)/putty
$(INSTALL_PROGRAM) -m 755 puttygen $(DESTDIR)$(bindir)/puttygen
$(INSTALL_PROGRAM) -m 755 puttytel $(DESTDIR)$(bindir)/puttytel
$(INSTALL_DATA) -m 644 ../doc/pageant.1 $(DESTDIR)$(man1dir)/pageant.1
$(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
# List the man pages for the automake makefile.
!begin am
if HAVE_GTK
man1_MANS = doc/plink.1 doc/pscp.1 doc/psftp.1 doc/puttygen.1 \
doc/pageant.1 doc/pterm.1 doc/putty.1 doc/puttytel.1
else
man1_MANS = doc/plink.1 doc/pscp.1 doc/psftp.1 doc/puttygen.1
endif
!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
# 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
rm -rf $@ && PUTTY_GTK_PREFIX_FROM_MAKEFILE=$$(pkg-config --variable=prefix gtk+-3.0) gtk-mac-bundler $<
unix/Pterm.app: unix/pterm.bundle ptermapp osxlaunch
rm -rf $@ && PUTTY_GTK_PREFIX_FROM_MAKEFILE=$$(pkg-config --variable=prefix gtk+-3.0) gtk-mac-bundler $<
endif
!end
# 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().
# WINVER etc perform a similar function for FlashWindowEx().
CFLAGS += -D_WIN32_IE=0x0500
CFLAGS += -DWINVER=0x0500 -D_WIN32_WINDOWS=0x0410 -D_WIN32_WINNT=0x0500
!end
# ------------------------------------------------------------
# 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.
# conf.c and its dependencies.
CONF = conf marshal
# Terminal emulator and its (platform-independent) dependencies.
TERMINAL = terminal wcwidth ldiscucs logging tree234 minibidi
+ config dialog CONF
# GUI front end and terminal emulator (putty, puttytel).
GUITERM = TERMINAL window windlg winctrls sizetip winprint winutils
+ wincfg sercfg winhelp winjump sessprep
# Same thing on Unix.
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
+ x11misc gtkcomm sessprep
GTKMAIN = gtkmain cmdline
# Non-SSH back ends (putty, puttytel, plink).
NONSSH = telnet raw rlogin ldisc pinger
# SSH back end (putty, plink, pscp, psftp).
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
SSHCOMMON = sshcommon sshrand
+ sshverstring sshcrc sshdes sshmd5 sshrsa sshsha sshblowf
+ sshdh sshcrcda sshpubk sshzlib sshdss ssharcf
+ sshaes sshccp sshsh256 sshsh512 sshbn sshmac marshal nullplug
+ sshgssc pgssapi sshecc wildcard ssh1censor ssh2censor ssh2bpp
+ 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
WINSSH = SSH winnoise wincapi winpgntc wingss winshare winnps winnpc
+ winhsock errsock
UXSSH = SSH uxnoise uxagentc uxgss uxshare
# SFTP implementation (pscp, psftp).
SFTP = sftp sftpcommon logging cmdline
New centralised binary-data marshalling system. I've finally got tired of all the code throughout PuTTY that repeats the same logic about how to format the SSH binary primitives like uint32, string, mpint. We've got reasonably organised code in ssh.c that appends things like that to 'struct Packet'; something similar in sftp.c which repeats a lot of the work; utility functions in various places to format an mpint to feed to one or another hash function; and no end of totally ad-hoc stuff in functions like public key blob formatters which actually have to _count up_ the size of data painstakingly, then malloc exactly that much and mess about with PUT_32BIT. It's time to bring all of that into one place, and stop repeating myself in error-prone ways everywhere. The new marshal.h defines a system in which I centralise all the actual marshalling functions, and then layer a touch of C macro trickery on top to allow me to (look as if I) pass a wide range of different types to those functions, as long as the target type has been set up in the right way to have a write() function. This commit adds the new header and source file, and sets up some general centralised types (strbuf and the various hash-function contexts like SHA_State), but doesn't use the new calls for anything yet. (I've also renamed some internal functions in import.c which were using the same names that I've just defined macros over. That won't last long - those functions are going to go away soon, so the changed names are strictly temporary.)
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.
MISC = misc 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
New centralised binary-data marshalling system. I've finally got tired of all the code throughout PuTTY that repeats the same logic about how to format the SSH binary primitives like uint32, string, mpint. We've got reasonably organised code in ssh.c that appends things like that to 'struct Packet'; something similar in sftp.c which repeats a lot of the work; utility functions in various places to format an mpint to feed to one or another hash function; and no end of totally ad-hoc stuff in functions like public key blob formatters which actually have to _count up_ the size of data painstakingly, then malloc exactly that much and mess about with PUT_32BIT. It's time to bring all of that into one place, and stop repeating myself in error-prone ways everywhere. The new marshal.h defines a system in which I centralise all the actual marshalling functions, and then layer a touch of C macro trickery on top to allow me to (look as if I) pass a wide range of different types to those functions, as long as the target type has been set up in the right way to have a write() function. This commit adds the new header and source file, and sets up some general centralised types (strbuf and the various hash-function contexts like SHA_State), but doesn't use the new calls for anything yet. (I've also renamed some internal functions in import.c which were using the same names that I've just defined macros over. That won't last long - those functions are going to go away soon, so the changed names are strictly temporary.)
2018-05-24 11:17:13 +03:00
WINMISC = MISCNET winstore winnet winhandl cmdline windefs winmisc winproxy
+ wintime winhsock errsock winsecur winucs miscucs
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
UXMISC = MISCNET UXMISCCOMMON uxproxy
# SSH server.
SSHSERVER = SSHCOMMON sshserver settings be_none logging ssh2kex-server
+ ssh2userauth-server sshrsag sshprime ssh2connection-server
+ sesschan sftpcommon sftpserver proxy cproxy ssh1login-server
+ ssh1connection-server scpserver
# import.c and dependencies, for PuTTYgen-like utilities that have to
# load foreign key files.
IMPORT = import sshbcrypt sshblowf marshal
# Character set library, for use in pterm.
CHARSET = sbcsdat slookup sbcs utf8 toucs fromucs xenc mimeenc macenc localenc
# Standard libraries.
LIBS = advapi32.lib user32.lib gdi32.lib comdlg32.lib
+ shell32.lib imm32.lib ole32.lib
# 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
BE_SSH = be_ssh cproxy
BE_NONE = be_none nocproxy
# 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
# And with the Unix serial-port module.
U_BE_ALL = be_all_s uxser cproxy
U_BE_NOSSH = be_nos_s uxser nocproxy
# ------------------------------------------------------------
# Definitions of actual programs. The program name, followed by a
# colon, followed by a list of objects. Also in the list may be the
# keywords [G] for Windows GUI app, [C] for Console app, [X] for
# X/GTK Unix app, [U] for command-line Unix app.
putty : [G] GUITERM NONSSH WINSSH W_BE_ALL WINMISC winx11 putty.res LIBS
puttytel : [G] GUITERM NONSSH W_BE_NOSSH WINMISC puttytel.res nogss LIBS
plink : [C] winplink wincons NONSSH WINSSH W_BE_ALL logging WINMISC
+ winx11 plink.res winnojmp sessprep noterm LIBS
pscp : [C] pscp winsftp wincons WINSSH BE_SSH SFTP wildcard WINMISC
+ pscp.res winnojmp LIBS
psftp : [C] psftp winsftp wincons WINSSH BE_SSH SFTP wildcard WINMISC
+ psftp.res winnojmp LIBS
pageant : [G] winpgnt pageant sshrsa sshpubk sshdes sshbn sshmd5 version
New centralised binary-data marshalling system. I've finally got tired of all the code throughout PuTTY that repeats the same logic about how to format the SSH binary primitives like uint32, string, mpint. We've got reasonably organised code in ssh.c that appends things like that to 'struct Packet'; something similar in sftp.c which repeats a lot of the work; utility functions in various places to format an mpint to feed to one or another hash function; and no end of totally ad-hoc stuff in functions like public key blob formatters which actually have to _count up_ the size of data painstakingly, then malloc exactly that much and mess about with PUT_32BIT. It's time to bring all of that into one place, and stop repeating myself in error-prone ways everywhere. The new marshal.h defines a system in which I centralise all the actual marshalling functions, and then layer a touch of C macro trickery on top to allow me to (look as if I) pass a wide range of different types to those functions, as long as the target type has been set up in the right way to have a write() function. This commit adds the new header and source file, and sets up some general centralised types (strbuf and the various hash-function contexts like SHA_State), but doesn't use the new calls for anything yet. (I've also renamed some internal functions in import.c which were using the same names that I've just defined macros over. That won't last long - those functions are going to go away soon, so the changed names are strictly temporary.)
2018-05-24 11:17:13 +03:00
+ tree234 MISC sshaes sshsha winsecur winpgntc aqsync sshdss sshsh256
+ sshsh512 winutils sshecc winmisc winhelp conf pageant.res LIBS
puttygen : [G] winpgen sshrsag sshdssg sshprime sshdes sshbn sshmd5 version
New centralised binary-data marshalling system. I've finally got tired of all the code throughout PuTTY that repeats the same logic about how to format the SSH binary primitives like uint32, string, mpint. We've got reasonably organised code in ssh.c that appends things like that to 'struct Packet'; something similar in sftp.c which repeats a lot of the work; utility functions in various places to format an mpint to feed to one or another hash function; and no end of totally ad-hoc stuff in functions like public key blob formatters which actually have to _count up_ the size of data painstakingly, then malloc exactly that much and mess about with PUT_32BIT. It's time to bring all of that into one place, and stop repeating myself in error-prone ways everywhere. The new marshal.h defines a system in which I centralise all the actual marshalling functions, and then layer a touch of C macro trickery on top to allow me to (look as if I) pass a wide range of different types to those functions, as long as the target type has been set up in the right way to have a write() function. This commit adds the new header and source file, and sets up some general centralised types (strbuf and the various hash-function contexts like SHA_State), but doesn't use the new calls for anything yet. (I've also renamed some internal functions in import.c which were using the same names that I've just defined macros over. That won't last long - those functions are going to go away soon, so the changed names are strictly temporary.)
2018-05-24 11:17:13 +03:00
+ sshrand winnoise sshsha winstore MISC winctrls sshrsa sshdss winmisc
+ sshpubk sshaes sshsh256 sshsh512 IMPORT winutils puttygen.res
+ tree234 notiming winhelp winnojmp CONF LIBS wintime sshecc
+ sshecdsag winsecur
pterm : [X] GTKTERM uxmisc misc ldisc settings uxpty uxsel BE_NONE uxstore
+ uxsignal CHARSET cmdline uxpterm version time xpmpterm xpmptcfg
+ nogss memory GTKMAIN
putty : [X] GTKTERM uxmisc misc ldisc settings uxsel U_BE_ALL uxstore
+ uxsignal CHARSET uxputty NONSSH UXSSH UXMISC ux_x11 xpmputty
+ xpmpucfg memory GTKMAIN
puttytel : [X] GTKTERM uxmisc misc ldisc settings uxsel U_BE_NOSSH
+ uxstore uxsignal CHARSET uxputty NONSSH UXMISC xpmputty xpmpucfg
+ nogss memory GTKMAIN
plink : [U] uxplink uxcons NONSSH UXSSH U_BE_ALL logging UXMISC uxsignal
+ ux_x11 noterm uxnogtk sessprep cmdline
PUTTYGEN_UNIX = sshrsag sshdssg sshprime sshdes sshbn sshmd5 version
New centralised binary-data marshalling system. I've finally got tired of all the code throughout PuTTY that repeats the same logic about how to format the SSH binary primitives like uint32, string, mpint. We've got reasonably organised code in ssh.c that appends things like that to 'struct Packet'; something similar in sftp.c which repeats a lot of the work; utility functions in various places to format an mpint to feed to one or another hash function; and no end of totally ad-hoc stuff in functions like public key blob formatters which actually have to _count up_ the size of data painstakingly, then malloc exactly that much and mess about with PUT_32BIT. It's time to bring all of that into one place, and stop repeating myself in error-prone ways everywhere. The new marshal.h defines a system in which I centralise all the actual marshalling functions, and then layer a touch of C macro trickery on top to allow me to (look as if I) pass a wide range of different types to those functions, as long as the target type has been set up in the right way to have a write() function. This commit adds the new header and source file, and sets up some general centralised types (strbuf and the various hash-function contexts like SHA_State), but doesn't use the new calls for anything yet. (I've also renamed some internal functions in import.c which were using the same names that I've just defined macros over. That won't last long - those functions are going to go away soon, so the changed names are strictly temporary.)
2018-05-24 11:17:13 +03:00
+ sshrand uxnoise sshsha MISC sshrsa sshdss uxcons uxstore uxmisc
+ sshpubk sshaes sshsh256 sshsh512 IMPORT puttygen.res time tree234
+ uxgen notiming CONF sshecc sshecdsag uxnogtk
puttygen : [U] cmdgen PUTTYGEN_UNIX
cgtest : [UT] cgtest PUTTYGEN_UNIX
pscp : [U] pscp uxsftp uxcons UXSSH BE_SSH SFTP wildcard UXMISC uxnogtk
psftp : [U] psftp uxsftp uxcons UXSSH BE_SSH SFTP wildcard UXMISC uxnogtk
pageant : [X] uxpgnt uxagentc aqsync pageant sshrsa sshpubk sshdes sshbn
+ sshmd5 version tree234 misc sshaes sshsha sshdss sshsh256 sshsh512
+ sshecc CONF uxsignal nocproxy nogss be_none x11fwd ux_x11 uxcons
+ gtkask gtkmisc nullplug logging UXMISC uxagentsock memory
ptermapp : [XT] GTKTERM uxmisc misc ldisc settings uxpty uxsel BE_NONE uxstore
+ uxsignal CHARSET uxpterm version time xpmpterm xpmptcfg
+ nogss gtkapp nocmdline memory
puttyapp : [XT] GTKTERM uxmisc misc ldisc settings uxsel U_BE_ALL uxstore
+ uxsignal CHARSET uxputty NONSSH UXSSH UXMISC ux_x11 xpmputty
+ xpmpucfg gtkapp nocmdline memory
osxlaunch : [UT] osxlaunch
fuzzterm : [UT] UXTERM CHARSET misc version uxmisc uxucs fuzzterm time settings
+ uxstore be_none uxnogtk memory
testbn : [UT] testbn sshbn MISC version CONF tree234 uxmisc uxnogtk
testbn : [C] testbn sshbn MISC version CONF tree234 winmisc LIBS
testzlib : [UT] testzlib sshzlib 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
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
# ----------------------------------------------------------------------
# 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:
-del $(BUILDDIR)testbn.exe
!end
!begin clangcl
cleantestprogs:
-rm -f $(BUILDDIR)testbn.exe
!end