Cope with REG_SZ data not having a trailing NUL.

A user points out that the person who writes a REG_SZ into the
registry can choose whether or not to NUL-terminate it properly, and
if they don't, RegQueryValueEx will retrieve it without the NUL. So if
someone does that to PuTTY's saved session data, then PuTTY may
retrieve nonsense strings.

Arguably this is the fault of whoever tampered with the saved session
data without doing it the same way we would have, but even so, there
ought to be some handling at our end other than silently returning the
wrong data, and putting the NUL back on seems more sensible than
complaining loudly.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10215 cda61777-01e9-0310-a592-d414129be87e
Close the listening socket when a sharing upstream dies.

Without this, doing 'Restart Session' on Windows in a session with
sharing enabled but no actual sharing being done would crash, because
the first incarnation of the session would become an upstream and
establish a listening named pipe, which then wouldn't get cleaned up
when the session closed, so the restarted session would try to connect
to it, triggering a call to plug_accepting on a freed sharestate.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10216 cda61777-01e9-0310-a592-d414129be87e
Handle save/load of set-typed config items.

I'm about to introduce a configuration option which is really a _set_
of string values (rather than an ordered list), and I'm going to
represent it in Conf as a string->string map (since that's a data type
we already support) in which every key which exists at all maps to the
empty string.

This change modifies settings.c so that it can write out such options
into the saved session as a comma-separated list of the key strings
only, rather than the form 'string1=,string2=,string3=' which you'd
get if you just used the existing wmap().

(Reading the result back in turns out not to need a code change - the
existing code already does what we want if it's reading a list of
key=value pairs and one of them doesn't have an = sign at all.)


git-svn-id: svn://svn.tartarus.org/sgt/putty@10217 cda61777-01e9-0310-a592-d414129be87e
Move base64_decode_atom into misc.c.

I'm about to need to refer to it from a source file that won't
necessarily always be linked against sshpubk.c, so it needs to live
somewhere less specialist. Now it sits alongside base64_encode_atom
(already in misc.c for another reason), which is neater anyway.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10218 cda61777-01e9-0310-a592-d414129be87e
Add an option to suppress horizontal scroll bars in list boxes.

I'm about to add a list box which expects to contain some very long
but uninformative strings, and which is also quite vertically squashed
so there's not much room for a horizontal scroll bar to appear in it.
So here's an option in the list box specification structure which
causes the constructed GTKTreeView to use the 'ellipsize' option for
all its cell renderers, i.e. too-long strings are truncated with an
ellipsis.

Windows needs no change, because its list boxes already work this way.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10219 cda61777-01e9-0310-a592-d414129be87e
New option to manually configure the expected host key(s).

This option is available from the command line as '-hostkey', and is
also configurable through the GUI. When enabled, it completely
replaces all of the automated host key management: the server's host
key will be checked against the manually configured list, and the
connection will be allowed or disconnected on that basis, and the host
key store in the registry will not be either consulted or updated.

The main aim is to provide a means of automatically running Plink,
PSCP or PSFTP deep inside Windows services where HKEY_CURRENT_USER
isn't available to have stored the right host key in. But it also
permits you to specify a list of multiple host keys, which means a
second use case for the same mechanism will probably be round-robin
DNS names that select one of several servers with different host keys.

Host keys can be specified as the standard MD5 fingerprint or as an
SSH-2 base64 blob, and are canonicalised on input. (The base64 blob is
more unwieldy, especially with Windows command-line length limits, but
provides a means of specifying the _whole_ public key in case you
don't trust MD5. I haven't bothered to provide an analogous mechanism
for SSH-1, on the basis that anyone worrying about MD5 should have
stopped using SSH-1 already!)


git-svn-id: svn://svn.tartarus.org/sgt/putty@10220 cda61777-01e9-0310-a592-d414129be87e
Change the naming policy for connection-sharing Unix sockets.

I had initially assumed that, since all of a user's per-connection
subdirectories live inside a top-level putty-connshare.$USER directory
that's not accessible to anyone else, there would be no need to
obfuscate the names of the internal directories for privacy, because
nobody would be able to look at them anyway.

Unfortunately, that's not true: 'netstat -ax' run by any user will
show up the full pathnames of Unix-domain sockets, including pathname
components that you wouldn't have had the access to go and look at
directly. So the Unix connection sharing socket names do need to be
obfuscated after all.

Since Unix doesn't have Windows's CryptProtectMemory, we have to do
this manually, by creating a file of random salt data inside the
top-level putty-connshare directory (if there isn't one there already)
and then hashing that salt with the "user@host" connection identifier
to get the socket directory name. What a pain.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10222 cda61777-01e9-0310-a592-d414129be87e
Fix a FIXME and a markup error in the manual host key docs.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10224 cda61777-01e9-0310-a592-d414129be87e
Don't show SSH connection sharing options mid-session (they don't work).


git-svn-id: svn://svn.tartarus.org/sgt/putty@10228 cda61777-01e9-0310-a592-d414129be87e
Update command-line help and man pages for -hostkey.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10229 cda61777-01e9-0310-a592-d414129be87e
Move -sercfg out of the "SSH only" section of command-line help.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10230 cda61777-01e9-0310-a592-d414129be87e
Update transcripts for recent command-line help changes.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10231 cda61777-01e9-0310-a592-d414129be87e
Add some index terms for host key overrides.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10232 cda61777-01e9-0310-a592-d414129be87e
Bodge around the failing Coverity build in winshare.c.

The winegcc hack I use for my Coverity builds is currently using a
version of wincrypt.h that's missing a couple of constants I use.
Ensure they're defined by hand, but (just in case I defined them
_wrong_) also provide a command-line define so I can do that only in
the case of Coverity builds.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10234 cda61777-01e9-0310-a592-d414129be87e
Correct man page description of -hostkey to match actual behaviour.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10235 cda61777-01e9-0310-a592-d414129be87e
Rework versioning system to not depend on Subversion.

I've shifted away from using the SVN revision number as a monotonic
version identifier (replacing it in the Windows version resource with
a count of days since an arbitrary epoch), and I've removed all uses
of SVN keyword expansion (replacing them with version information
written out by Buildscr).

While I'm at it, I've done a major rewrite of the affected code which
centralises all the computation of the assorted version numbers and
strings into Buildscr, so that they're all more or less alongside each
other rather than scattered across multiple source files.

I've also retired the MD5-based manifest file system. A long time ago,
it seemed like a good idea to arrange that binaries of PuTTY would
automatically cease to identify themselves as a particular upstream
version number if any changes were made to the source code, so that if
someone made a local tweak and distributed the result then I wouldn't
get blamed for the results. Since then I've decided the whole idea is
more trouble than it's worth, so now distribution tarballs will have
version information baked in and people can just cope with that.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10262 cda61777-01e9-0310-a592-d414129be87e
Add a missing bounds check in the Deflate decompressor.

The symbol alphabet used for encoding ranges of backward distances in
a Deflate compressed block contains 32 symbol values, but two of them
(symbols 30 and 31) have no meaning, and hence it is an encoding error
for them to appear in a compressed block. If a compressed file did so
anyway, this decompressor would index past the end of the distcodes[]
array. Oops.

This is clearly a bug, but I don't believe it's a vulnerability. The
nonsense record we load from distcodes[] in this situation contains an
indeterminate bogus value for 'extrabits' (how many more bits to read
from the input stream to complete the backward distance) and also for
the offset to add to the backward distance after that. But neither of
these can lead to a buffer overflow: if extrabits is so big that
dctx->nbits (which is capped at 32) never exceeds it, then the
decompressor will simply swallow all further data without producing
any output, and otherwise the decompressor will consume _some_ number
of spare bits from the input, work out a backward distance and an
offset in the sliding window which will be utter nonsense and probably
out of bounds, but fortunately will then AND the offset with 0x7FFF at
the last minute, which makes it safe again. So I think the worst that
a malicious compressor can do is to cause the decompressor to generate
strange data, which of course it could do anyway if it wanted to by
sending that same data legally compressed.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10278 cda61777-01e9-0310-a592-d414129be87e
Turn mkunxarc.sh back into an ordinary sh script.

It became bash-dependent in r9229 because I used a bashism to remove
the 'r' from the front of $SVN_REV, but that's not needed any more.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10281 cda61777-01e9-0310-a592-d414129be87e