Fix a few more clang-generated warnings.

These are benign, I think. clang warns about casting non-pointer-sized
integers to pointers, but the Windows API actually does sometimes
involve values that are either pointers or _small_ integers, so in the
two cases involved I just cast through ULONG_PTR to silence the
warning. And clang insists that the integer whose address I give to
sk_getxdmdata is still uninitialised afterwards, which is just a lie.

Stop using MS-deprecated names stricmp and strnicmp.

clang-cl generates warnings saying they're deprecated, in favour of
the same names but prefixed with an underscore. The warnings are
coming from the standard MS headers, and I'm already #defining those
names differently on Unix, so I'll honour them.

clang-specific pragmas to suppress -Wmissing-braces.

When I added some extra braces in commit 095072fa4 to suppress this
warning, I think in fact I did the wrong thing, because the
declaration syntax I was originally using is the Microsoft-recommended
one in spite of clang not liking it - I think MS would be within their
rights (should they feel like it) to add those missing braces in a
later version of the WinSock headers, which would make the current
warning-clean code stop compiling. So it's better to put the code back
as it was, and avoid the clang warning by using clang's
warning-suppression pragmas for just those declarations.

I've also done the same thing in winnet.c, for two initialisers of
IPv6 well-known addresses which had the same problem (but which I
didn't notice yesterday because a misjudged set of Windows version
macros had prevented me from compiling that file successfully at all).

New makefile, for Windows cross-builds with clang-cl.

This was very strange to write, because it's a bizarre combination of
the GNU-make-isms and rc commands of Makefile.mgw with the cl and link
commands of Makefile.vc (but also the latter thankfully doesn't need
those horrible response files).

I've added a big comment in mkfiles.pl about what the build
requirements for this makefile actually are, which _hopefully_ will be
usable by people other than me.

Log proxy host correctly in Event Log.

We were showing the destination hostname -- oops.

Document Inno Setup's new lack of cleanup.

We used to offer to clean up saved sessions, so we should mention that
we don't for the benefit of users of old versions, who might have been
relying on it.

Note legacy status of putty.iss.

Also correct last tested version.

Document '-restrict-acl' vs subprocesses.

(Since we've thought about it.)

Reference '-proxycmd' from main local proxy docs.

Pass -restrict-acl, if given, through to sub-PuTTYs.

This change applies to every situation when GUI PuTTY knowingly spawns
another GUI PuTTY, to wit, the System menu options 'New Session',
'Duplicate Session' and the 'Saved Sessions' submenu.

(Literally speaking, what we actually pass through to the sub-PuTTY's
command line is not the "-restrict-acl" option itself, but a special
prefix "&R", which has the same meaning but which lives in the special
pre-argv-splitting command-line namespace like the magic options used
for Duplicate Session and the old '@sessionname' prefix which the
Saved Sessions submenu still uses. Otherwise, by the time we split up
argv and recognised -restrict-acl, it would be too late to parse those
other options.)

One case in which PuTTY spawns a subprocess and this change _doesn't_
apply is when the subprocess is a proxy command which happens to be a
Plink. Recognising Plink commands in that situation would be fragile
and unreliable, and in any case if the user wants a proxy Plink to be
ACL-restricted, they are in control of its exact command line so they
can add -restrict-acl themselves.

A bunch of further warning fixes in the Windows code.

These ones are stylistic rather than potential bugs: mostly signedness
of char pointers in cases where they clearly aren't going to cause the
wrong thing to actually happen, and one thing in winsecur.c where
clang would have preferred an extra pair of braces around some
initialisers but it's legal with or without. But since some of clang's
warnings turn out to be quite useful, it seems worth silencing these
harmless ones so as to be able to see the rest.

Missing initialisation in winsecur.c.

We might have returned true from getsids() by mistake, even if
something had gone wrong. Thanks again, clang.

Move declaration of frontend_is_utf8 into putty.h.

It's a function that exists on all platforms, not just on Unix - it's
used in ldisc.c - so it shouldn't have been declared only in unix.h.
Score another for clang's warnings.

Fix an EOF-testing goof in winhandl.c.

I was having a play with clang's MSVC compatibility mode, just to see
how much of PuTTY it could compile, and one of its warnings pointed
out this error which must have crept in when I was changing the EOF
flags in winhandl.c from booleans to three-state enums - I left the !
on the front of what was previously an if (!thing) and needed to turn
into if (thing == EOF_NO).

Fix error reporting pointer parameters in winsecur.c.

Several functions were passing a 'char *error' and assigning error
messages directly into 'error', where they should have been passing
'char **error' and assigning error messages into '*error' if the error
message is to be returned to the caller. This would have led to
incomplete error messages.

Remove duplicate definition of AGENT_MAX_MSGLEN.

Now all references of that constant use the same definition in
pageant.h, so it'll be easy to change if we ever need to.

Refuse to forward agent messages > AGENT_MAX_MSGLEN.

Mostly so that we don't have to malloc contiguous space for them
inside PuTTY; since we've already got a handy constant saying how big
is too big, we might as well use it to sanity-check the contents of
our agent forwarding channels.

Turn off Windows process ACL restriction by default.

As documented in bug 'win-process-acl-finesse', we've had enough
assorted complaints about it breaking various non-malicious pieces of
Windows process interaction (ranging from git->plink integration to
screen readers for the vision-impaired) that I think it's more
sensible to set the process back to its default level of protection.

This precaution was never a fully effective protection anyway, due to
the race condition at process startup; the only properly effective
defence would have been to prevent malware running under the same user
ID as PuTTY in the first place, so in that sense, nothing has changed.
But people who want the arguable defence-in-depth advantage of the ACL
restriction can now turn it on with the '-restrict-acl' command-line
option, and it's up to them whether they can live with the assorted
inconveniences that come with it.

In the course of this change, I've centralised a bit more of the
restriction code into winsecur.c, to avoid repeating the error
handling in multiple places.

Tweak bounds checks in pageant_add_keyfile.

When we're going through the response from an SSH agent we asked for a
list of keys, and processing the string lengths in the SSH-2 sequence
of (public blob, comment) pairs, we were adding 4 to each string
length, and although we checked if the result came out to a negative
value (if interpreted as a signed integer) or a positive one going
beyond the end of the response buffer, we didn't check if it wrapped
round to a positive value less than 4. As a result, if an agent
returned malformed data sent a length field of 0xFFFFFFFC, the pointer
would advance no distance at all through the buffer, and the next
iteration of the loop would check the same length field again.

(However, this would only consume CPU pointlessly for a limited time,
because the outer loop up to 'nkeys' would still terminate sooner or
later. Also, I don't think this can sensibly be classed as a serious
security hazard - it's arguably a borderline DoS, but it requires a
hostile SSH _agent_ if data of that type is to be sent on purpose, and
an untrusted SSH agent is not part of the normal security model!)

Rewrite agent forwarding to serialise requests.

The previous agent-forwarding system worked by passing each complete
query received from the input to agent_query() as soon as it was
ready. So if the remote client were to pipeline multiple requests,
then Unix PuTTY (in which agent_query() works asynchronously) would
parallelise them into many _simultaneous_ connections to the real
agent - and would not track which query went out first, so that if the
real agent happened to send its replies (to what _it_ thought were
independent clients) in the wrong order, then PuTTY would serialise
the replies on to the forwarding channel in whatever order it got
them, which wouldn't be the order the remote client was expecting.

To solve this, I've done a considerable rewrite, which keeps the
request stream in a bufchain, and only removes data from the bufchain
when it has a complete request. Then, if agent_query decides to be
asynchronous, the forwarding system waits for _that_ agent response
before even trying to extract the next request's worth of data from
the bufchain.

As an added bonus (in principle), this gives agent-forwarding channels
some actual flow control for the first time ever! If a client spams us
with an endless stream of rapid requests, and never reads its
responses, then the output side of the channel will run out of window,
which causes us to stop processing requests until we have space to
send responses again, which in turn causes us to stop granting extra
window on the input side, which serves the client right.

Make asynchronous agent_query() requests cancellable.

Now, instead of returning a boolean indicating whether the query has
completed or is still pending, agent_query() returns NULL to indicate
that the query _has_ completed, and if it hasn't, it returns a pointer
to a context structure representing the pending query, so that the
latter can be used to cancel the query if (for example) you later
decide you need to free the thing its callback was using as a context.

This should fix a potential race-condition segfault if you overload an
agent forwarding channel and then close it abruptly. (Which nobody
will be doing for sensible purposes, of course! But I ran across this
while stress-testing other aspects of agent forwarding.)

Remove the commented-out WINDOWS_ASYNC_AGENT code.

It's been commented out for ages because it never really worked, and
it's about to become further out of date when I make other changes to
the agent client code, so it's time to get rid of it before it gets in
the way.

If and when I do get round to supporting asynchronous agent requests
on Windows, it's now pretty clear to me that trying to coerce this
ghastly window-message IPC into the right shape is the wrong way, and
a better approach will be to make Pageant support a named-pipe based
alternative transport for its agent connections, and speaking the
ordinary stream-oriented agent protocol over that. Then Pageant will
be able to start adding interactive features (like confirmation
dialogs or on-demand decryption) with freedom to reply to multiple
simultaneous agent connections in whatever order it finds convenient.

Fix Makefile warning about circular empty.h dependency.

In commit be586d53b I made empty.h depend on $(allsources), which
unfortunately was defined so as to include empty.h. This was harmless,
because make just ignored the circular dependency, but annoying,
because it constantly mentioned that it was ignoring it.

Report the right address in connection setup errors.

backend_socket_log was generating the IP address in its error messages
by means of calling sk_getaddr(). But sk_getaddr only gets a SockAddr,
which may contain a whole list of candidate addresses; it doesn't also
get the information stored in the 'step' field of the Socket that was
actually trying to make the connection, which says _which_ of those
addresses we were in the middle of trying to connect to.

So now we construct a temporary SockAddr that points at the
appropriate one of the addresses, and use that for calls to plug_log
during connection setup.

Rework handling of asynchronous connect(2) errors on Unix.

If connect() returns EINPROGRESS, then previously we would detect a
successful connection by the socket becoming selectable for writing,
and spot an unsuccessful one by an error code being returned on the
first attempt to read from it.

This isn't the right way to do it: the right way is to respond to the
initial writability notification by calling getsockopt(SO_ERROR) to
retrieve the error code (if any) from the completed connection
attempt. Doing it the old way had the problem that when the socket
became writable, we could sometimes already have written some of our
outgoing data to it before finding out that the connect attempt failed
- which meant we'd discard that data from the bufchain, and no longer
have it to send through a later successful connection to a different
candidate address.

Fix an integer overflow in get_ssh_string.

If the length field in the input data was so large that adding 4 to it
caused wraparound, the error check could fail to trigger. Fortunately,
this praticular get_ssh_string function is only used during private
key import from foreign file formats, so it won't be facing hostile
data.

Fix a memory leak in openssh_loadpub

The line read from the input file was not freed after successfully
loading an OpenSSH key.

Fix a memory leak in rsakey_pubblob

The line read from the input file was not freed after successfully
loading an SSH1 key.

Fix resource leak in rsakey_pubblob

The input file was not closed after successfully loading an SSH1 key.

Fix memory leak in bignum_from_decimal

Intermediate result values were not freed.

Fix memory leak in ed25519_openssh_createkey

If q could not be read from the input blob, the allocated ec_key
structure was not freed.

Add error variable to loop condition

In case of connection errors before and during the handshake,
net_select_result is retrying with the next address of the server. It
however was immediately going to the last address as it was not
checking the return value of try_connect for all intermediate
addresses.

We routinely compile with both VS2003 and 2015.

It's a new year.

Fix misspelled redirect of the 64-bit installer.

The .htaccess written by Buildscr into the w64 directory was applying
a redirect from 'putty-installer.msi', but in fact the name by which
the website links to snapshot and prerelease installers in that
directory is 'putty-64bit-installer.msi'.

Rename the maps directory in release.pl.

The code that copies the link maps of the release Windows builds into
the place I store them for later debugging should now not
embarrassingly look in the wrong place when we make our first
post-VS2015 release.

Checklist updates from the website revamp.

I've now made a new section about how to turn on pre-release mode,
because although it's been carefully made trivial within the website
repo itself, there are still several things in other places I need to
edit.

Also added a note to myself to turn off nightly pre-release builds
after the release has gone out. I found on a previous occasion that my
build machine had been building them for months after they were
needed, which was harmless to the website but a waste of CPU!

Conditionalise the automake git-commit embedding.

This arranges that the mechanism from the previous commit
automatically turns itself on and off depending on whether a .git
directory even exists (so it won't try to do anything in distribution
tarballs), and also arranges that it can be manually turned off by a
configure option (in case someone who _is_ building from a git
checkout finds it inconvenient for some reason I haven't thought of,
which seems quite plausible to me).

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.

Make bob builds show the full source git commit hash in buildinfo.

The Windows binaries, and both Windows and Unix source archives,
output from a bob build will now include the full SHA-1 of the source
git commit in their buildinfo (hence in all the About boxes and
command-line version output).

This will be occasionally useful to me at release time (there was that
one embarrassing incident where I managed not to notice that I'd made
a release build from entirely the wrong commit), but mostly, it just
seems like an obviously useful thing to put in a general buildinfo
section now that there is one.

Include 'build info' in all --version text and About boxes.

This shows the build platform (32- vs 64-bit in particular, and also
whether Unix GTK builds were compiled with or without the X11 pieces),
what compiler was used to build the binary, and any interesting build
options that might have been set on the make command line (especially,
but not limited to, the security-damaging ones like NO_SECURITY or
UNPROTECT). This will probably be useful all over the place, but in
particular it should allow the different Windows binaries to be told
apart!

Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by
allowing the various About boxes to contain free text and also
ensuring they could be copied and pasted easily as part of a bug
report.

Add a 'strbuf' system, for building up a large string piece by piece.

I'm faintly surprised I haven't needed this before. Basically it's an
allocating string formatter, like dupprintf, except that it
concatenates on to the end of a previous string. You instantiate a
strbuf, then repeatedly call strbuf_catf to append pieces of formatted
output to it, and then you can extract the whole string and free it
(separately or both in one step).

Fix PE header of the VS2015 builds so they run on Windows XP.

By default the VS2015 linker produces binaries with the minimum
version fields in the PE header set to 06.00, which causes XP not to
recognise them as valid binaries at all. But there's no other reason
VS2015-built binaries _can't_ run on versions of Windows as old as XP;
so here I add the link option to set those fields to 05.01 which makes
XP like them again.

This only applies to the 32-bit build, because the VS2015 64-bit
linker refuses to lower the min version field to under 06.00.

Reinstate the ASLR and DEP linker flags on Windows.

Originally added in commit 0014ffb70, and promptly reverted in
6bea4b250 when we realised that VS2003 didn't actually understand
them. But now we're building with VS2015, which does understand them,
it's actually useful to put them back in again.

Looking more closely, it turns out that VS2003 didn't actually _fail
to build_ if you passed these flags on the linker command line - it
just printed a warning and ignored them. (So there was no actual need
to revert the original change, except that it would have caused
confusion.) But that means I can add them unconditionally now, without
breaking even the legacy VS2003 build.

Remove 'putty -cleanup-during-uninstall' from legacy uninstaller.

It's a bit conceptually incoherent anyway - if you're uninstalling
PuTTY _systemwide_ across a multi-user system, it doesn't really make
sense that you'd also want to wipe the saved sessions for the
individual user running the uninstaller.

Also, making this change to the Inno Setup uninstaller opens up a
nicer migration path to MSI for people doing large corporate rollouts:
they can upgrade to this version of the Inno Setup package, then do a
silent uninstall of it (which should now _actually_ be silent, since
this cleanup step was the thing that interrupted it otherwise) and
then a silent install of the MSI.

Comment that Inno Setup installer remains 32-bit only.

Our Inno Setup installer is legacy as far as I'm concerned, so there's
no point in introducing a 64-bit version of it. 64-bit PuTTY users can
use the MSI from the start, and then there'll only ever have been one
kind of installer and they won't collide with one another.

Name the 64-bit MSI distinctively.

The 32- and 64-bit installers may be distinguishable by their pathname
in the build output directory, but it's better to have their actual
filenames be different as well, so they don't collide in people's
download directories.

Build an MSI installer for the new Win64 binaries.

The MSI format has a fixed field for target architecture, so there's
no way to build a single MSI that can decide at install time whether
to install 32-bit or 64-bit (or both). The best you can do along those
lines, apparently, is to have two MSI files plus a bootstrap .EXE that
decides which of them to run, and as far as I'm concerned that would
just reintroduce all the same risks and annoyances that made us want
to migrate away from .EXE installers anyway.

Build a set of Windows 32-bit 'legacy' binaries with VS2003.

The downside of moving to VS2015 is that its output won't run on very
old versions of Windows. It's not yet clear whether anyone still cares
about things before, say, Win2000 or WinXP, but since my build
environment still _has_ VS2003 available, it's easy enough to build
the extra set of binaries anyway just in case. (At least for now.)

The new binaries live in a build output directory 'w32old'. As with
w64, there is no installer for them; but unlike w64, I don't intend to
add one.

Build 64-bit Windows binaries, alongside the 32-bit ones.

Now we've got VS2015 available (and thanks to a lot of 64-bit
cleanness fixing, in particular Tim Kosse's large patch series from
August 2015) we can do this fairly easily.

The new binaries are shipped in a 'w64' directory, alongside the
just-renamed 'w32'. There is no 64-bit installer (yet).

Switch the main Windows build to Visual Studio 2015.

This is a big jump from the previous VS2003. It should add a little
performance (VS2015 is a better-optimising compiler), but mostly it's
groundwork for doing other useful things such as 64-bit builds and
security-related linker features.

The downside is reduced support for very old versions of Windows,
which I'll address shortly.

Rename the 'x86' build output directory to 'w32'.

This change does affect the layout of the output build directory, and
will need corresponding website changes to avoid breaking links.

'x86' was a misnomer anyway, because it was really Windows-specific
rather than just x86-specific. Calling it 'w32' will make it look less
strange to add 'w64' alongside it.

Do the Windows build in a subdirectory windows/build32.

Uses the BUILDDIR mechanism I added to Makefile.vc in commit
d3db17f3e.

This change is purely internal to Buildscr, and shouldn't affect the
output of a build. It paves the way to have Buildscr run multiple
Windows builds using different compilers, by putting each one in a
different subdirectory so that their outputs don't collide.

x11font: fix handling of high-bit-set SBCS characters.

I had mistakenly pulled a 'char' value out of a string and passed it
to x11_font_has_glyph and x11_char_struct, each of which takes its two
index bytes as int-typed parameters. But if chars are signed, that
turns high-bit-set characters into out-of-range array indices. Oops.

The range checks in x11_char_struct prevented that from causing any
problem worse than refusal to display any affected glyph. Even so,
that's not particularly helpful. Fixed by changing the index byte
parameters to unsigned char type.

Fix memory leak: Free hostkey fingerprint when cross-certifying.

Add some missing checks for EINTR after select(2).

I noticed today that Unix Plink responds to SIGWINCH by accidentally
dying of EINTR having interrupted its main select loop, and when I
checked, there turn out to be a couple of other select loops with the
same bug.

Remove/rescope variable 'ret' in sftp_put_file.

This is a purely stylistic cleanup - no functional change intended -
after Tim Kosse's changes in commits e9a76883a and 6f871e3d2.

I think the underlying cause of the confusion whose functional effects
he was fixing there is that I have the bad habit of tending to call
variables 'ret' for two different reasons: one is because it's holding
the value returned from some subroutine I've just called, and the
other is because it's holding the value I'm preparing to return from
the routine _containing_ the variable.

The reason it's a bad habit is that I confuse the two purposes, and a
variable of one type ends up accidentally being treated as the other.
So while Tim's commits have already fixed the functional effects of
the error in this case, this change should help prevent a recurrence
because now there's no variable called 'ret' at all that's in scope
for the whole function.

In random_add_noise, put the hashed noise into the pool, not the raw noise

random_add_noise calls SHATransform for every 64 octets of incoming noise,
yet instead of xor'ing the hashed noise into the pool it instead only xor'ed
20 octets of the raw noise in each iteration. This effectively reduced the
amount of new entropy entering the pool.

Handle failed SSH_FXP_CLOSE requests in sftp_put_file.

It is possible for SSH_FXP_CLOSE requests to fail. This can happen if the
server buffers writes and an error occurs flushing the data to disk while
processing the SSH_FXP_CLOSE request. If the close fails, sftp_put_file now
returns an error as well.

Fix sftp_put_file returning success on failed transfers.

Due to a shadowed variable, transfer failures were not reflected in the return
code to sftp_put_file. Instead of tracking the return code, use the 'err'
variable to decide which return code to use.

Fix sftp_get_file returning success on failed transfers.

Due to the return variable 'ret' being shadowed in the transfer loop, errors
in the transfer loop did not affect the final return value of sftp_get_file.
This particularly affects psftp's batch mode (without passing the -be
command-line argument), which would errorneously continue. The solution is
to simply remove the shadowing declaration.

Fix a compile failure with NO_IPV6.

A user points out that buf[] in sk_tcp_peer_info is only used in the
IPv6 branch of an ifdef, and is declared with a size of
INET6_ADDRSTRLEN, which won't be defined in NO_IPV6 mode. So moving
the definition inside another IPv6-only ifdef fixes the resulting
build failure.

Fix type mismatch in sftp_find_request

The id member of the sftp_request structure is of type unsigned int.
This type is also used in the sftp_reqfind callback. In
sftp_find_request we thus need to pass a pointer to unsigned int to
find234. Before this commit, sftp_find_request was passing a pointer
to unsigned long to find234, which causes the lookup to fail on
big-endian platforms where sizeof(unsigned int) != sizeof(unsigned
long), e.g. ppc64.

Make ESC[3J (clear scrollback) a disableable escape sequence.

A user complained that it was being done nonconsensually, and it seems
reasonable that the user should have the choice to prevent it.

Make the new ^< and ^> keystrokes add the class prefix.

The new font name configured by the keystrokes was missing its
"client:" or "server:" prefix, which could have led to the selection
of the wrong font in rare situations.

Unix PuTTY/pterm: Ctrl-< / Ctrl-> to change font size.

Each gtkfont back end now provides a routine that will return the name
of a similar font to the current one but one notch larger or smaller.
For Pango, this is just a matter of incrementing the font size field
in a standard way; for X11 server-side fonts, we have to go and do an
XListFonts query with a wildcard that requests fonts that vary only in
the size fields from the current one, and then iterate over the result
looking for the best one.

(I expect this will be more useful to Pango scalable-font users than
to X11 fonts, but it seemed a shame not to give the X11 side my best
shot while I was at it.)

Choice of hotkey: I know I'm being inconsistent with gnome-terminal's
use of Ctrl-plus and Ctrl-minus. I thought that was because I was
already using Ctrl-minus as a more convenient synonym for
Ctrl-underscore (which sends the actual control code 0x1F), but now I
actually try it, apparently I'm not. However, Ctrl-plus and Ctrl-minus
are quite horrible as a keystroke pair anyway (one has to be typed
with shift and one without!), and I feel as if the 'less' and
'greater' signs are more specific anyway, in that they specifically
indicate _size_ rather than just 'unspecified numerical value'.

gtkfont: refactor parse/unparse of XLFDs.

There were already two places in the code (x11font_enum_fonts and
x11_guess_derived_font_name) where we retrieved an XLFD from the X
server, sawed it up ad-hoc into its '-'-separated parts and accessed
them by numeric index.

I'm about to add a third, so before I do, let's turn this into a
somewhat principled system where we get to do the decode/encode in
just one place and call all the individual fields by names that are
actually memorable.

No functional change intended by this commit.

release.pl: switch the.earth.li to HTTPS.

That's the URL scheme we advertise on the website, so it's silly to do
the release-time testing by any other system.

cygtermd: be more specific in define of _XOPEN_SOURCE.

On Debian stretch, it seems we don't get setpgrp() unless we do not
merely define it, but define it to 500 or greater.

Add explicit "./" in mkfiles.pl's require statements.

I've just tried for the first time to run mkfiles.pl on a system where
plain 'require "sbcsgen.pl"' does not search the cwd by default.

SetCurrentProcessExplicitAppUserModelID to fix jumplist/removable media bug

The algorithm Windows uses to generate AppUserModelIDs "hangs on" to
removable media (CDs/DVDs) if PuTTY is launched with a CD/DVD in a drive.
Set the AppUserModelID explicitly to avoid using this algorithm.

Fix memory leak in the new make_dir_path().

Thanks to Jason Andryuk for promptly pointing it out.

Added support for the XDG specification

The XDG configuration location ($XDG_CONFIG_HOME/putty, or
~/.config/putty) is now prefered over the old ~/.putty location, if the
XDG location already exists. If it doesn't exist, we try to use one of
the old locations ($HOME/.putty, [/etc/passwd home]/.putty, /.putty). If
none of the directories exist, we fall back to ~/.config/putty or
~/.putty, if the XDG_DEFAULT macro is defined or not, respectively. The
PUTTYDIR environment variable remains a definitive override of the
configuration location. This all ensures that the old location is still
used, unless the user explicitly requests otherwise.

The configuration directories are created using the make_dir_path()
function, to ensure that saving the configuration doesn't fail e.g.
because of a non-existent ~/.config directory.

New Unix utility function to make a directory path.

Essentially 'mkdir -p' - we try to make each prefix of the pathname,
terminating on any error other than EEXIST. Semantics are similar to
make_dir_and_check_ours(): we return NULL on success or a dynamically
allocated error message string on failure.

Lock down the search path for Windows DLL loading.

At least on systems providing SetDefaultDllDirectories, this should
stop PuTTY from being willing to load DLLs from its containing
directory - which makes no difference when it's been properly
installed (in which case the application dir contains no DLLs anyway),
but does if it's being run from somewhere uncontrolled like a browser
downloads directory.

Preliminary testing suggests that this shouldn't break any existing
deliberate use of DLLs, including GSSAPI providers.

clip_addchar: merge memory-management performance fix.

Speed up clipboard copies.

Copying large scrollback buffers to the clipboard can take a long time,
up to several minutes. Doubling the size of the clipboard copy buffer
when more space is needed, instead of just adding a small constant size,
significantly speeds up clipboard copies of large scrollback buffers.

Factor out code to close the local socket associated with a channel.

The only visible effect should be that abrupt closure of an SSH
connection now leads to a slew of messages about closing forwarded
ports.

Use ssh2_channel_got_eof() in ssh1_msg_channel_close().

Of course, that means renaming it to ssh_channel_got_eof().  It also
involves adding the assertions from ssh1_msg_channel_close(), just in
case.

Move call to ssh2_channnel_check_close().

From ssh2_channel_got_eof() to ssh2_msg_channel_eof().  This removes
the only SSH-2 specicifity from the former.  ssh2_channel_got_eof()
can also be called from ssh2_msg_channel_close(), but that calls
ssh2_channel_check_close() already.

Assume that u.pfd.pf and u.x11.xconn are not NULL on appropriate channels.

Nothing ever sets them to NULL, and the various paths by which the
channel types can be set to CHAN_X11 or CHAN_SOCKDATA all ensure thet
the relevant union members are non-NULL.  All the removed conditionals
have been converted into assertions, just in case  I'm wrong.

Don't completely ignore unknown types of SSH_MSG_CHANNEL_EXTENDED_DATA.

It's important to do the usual window accounting in all cases.  We
still ignore the data themselves, which I think is the right thing to
do.

Remove CHAN_SOCKDATA_DORMANT.

It's redundant with the halfopen flag and is a misuse of the channel
type field.  Happily, everything that depends on CHAN_SOCKDATA_DORMANT
also checks halfopen, so removing it is trivial.

Forward channel messages for shared channels in ssh_channel_msg().

This saves doing it separately in every function that processes such
messages.

More strictness in ssh_channel_msg().

Now it disconnects if the server sends
SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE for
a channel that isn't half-open.  Assertions in the SSH-2 handlers for
these messages rely on this behaviour even though it's never been
enforced before.

Switch SSH-1 channel message handlers to use ssh_channel_msg().

This gives consistent (and stricter) handling of channel messages
directed at non-existent and half-open channels.

Generalise ssh2_channel_msg() to ssh_channel_msg().

It now supports both SSH-1 and SSH-2 channel messages.  The SSH-1 code
doesn't yet use it, though.

Assert that ssh2_channel_check_close() is only called in SSH-2.

That really should be true, but I don't entirely trust
sshfwd_unclean_close().

In ssh_channel_init(), insert the new channel into the channel tree234.

All but one caller was doing this unconditionally.  The one conditional
call was when initialising the main channel, and in consequence PuTTY
leaked a channel structure when the server refused to open the main
channel.  Now it doesn't.

Convert ssh2_channel_init() into ssh_channel_init().

By adding support for initialising SSH-1 channels as well.  Now all
newly-created channels go through this function.

Unify despatch of incoming channel data between SSH-1 and SSH-2.

Don't send SSH_MSG_CHANNEL_WINDOW_ADJUST with a zero adjustment.

Factor out common parts of ssh_unthrottle and sshfwd_unthrottle.

The SSH-2 code is essentially all shared, but SSH-1 still has some
code specific to the stdout/stderr case.

Remove inaccurate comment about Unix getticks() function.

It's not always based on gettimeofday(); now it mostly uses
clock_gettime().

Document SSH IUTF8 mode.

Set SSH IUTF8 appropriately in Unix Plink.

Fix uninitialized variable in Windows get_file_posn.

The Windows implementation of get_file_posn is calling SetFilePointer
to obtain the current position in the file. However it did not
initialize the variable holding the high order 32-bit to 0. Thus,
SetFilePointer either returned -1 to indicate an error or did move the
file pointer to a different location instead of just returning the
current position. This change just initializes the variable to 0.

As a result, this bug has caused psftp's reget command to fail
resuming transfers or to create corrupt files due to setting up an
incorrect resume offset.

Rework samplekex.py to use the new -proxycmd.

It now expects its standard input to be connected to the same PuTTY
its standard output is talking to, i.e. expects to be invoked as a
proxy command. It conducts the same sample key exchange as it used to,
but now reads the SSH greeting and first couple of packets back from
PuTTY and minimally checks that they're something like what it was
expecting.

(In the process, I've also fixed a mistake in the Python message code
enumeration, which caused one of those expect() calls to fail.)

Add a '-proxycmd' command-line option.

This is equivalent to selecting 'Local' as the proxy type and entering
the argument string in the proxy command box, in the GUI.

I've pulled this out of all the other proxy options to promote to a
named command-line option, partly because it's the proxy option with
the most natural command-line expression in the first place (any shell
command you might want to use is already in the form of a single
string), and also because it has uses beyond end-user proxying
applications: in particular, replacing the network connection with a
local process is a convenient way to do testing in the style of
contrib/samplekex.py, avoiding the need to run a separate command to
make the test 'server' listen on a port.

Swap endianness of the Curve25519 ECDH private key.

DJB's spec at http://cr.yp.to/ecdh/curve25519-20060209.pdf is clear
that we should be clearing the low 3 bits of the _LSB_ of the private
key bit string, and setting bit 6 and clearing bit 7 of the _MSB_. We
were doing the opposite, due to feeding the resulting bit string to
bignum_from_bytes() rather than bignum_from_bytes_le().

This didn't cause an interoperability issue, because the two DH
exponentiations still commute, but it goes against the Curve25519
spec, in particular the care taken to fix the position of the leading
exponent bit.

The code is now consistent with the test vectors in RFC 7748 section
6.1: if you modify the EC_MONTGOMERY branch of ssh_ecdhkex_newkey() to
replace the loop on random_byte() with a memcpy that fills bytes[]
with 77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
and then print out the resulting publicKey->x, you find that it's
(byte-reversed) the expected output value given in that RFC section,
8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a.