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