Replace quaint references to floppies with "USB stick".


git-svn-id: svn://svn.tartarus.org/sgt/putty@10193 cda61777-01e9-0310-a592-d414129be87e
Implement this year's consensus on CHANNEL_FAILURE vs CHANNEL_CLOSE.

We now expect that after the server has sent us CHANNEL_CLOSE, we
should not expect to see any replies to our outstanding channel
requests, and conversely after we have sent CHANNEL_CLOSE we avoid
sending any reply to channel requests from the server. This was the
consensus among implementors discussing the problem on ietf-ssh in
April 2014.

To cope with current OpenSSH's (and perhaps other servers we don't
know about yet) willingness to send request replies after
CHANNEL_CLOSE, I introduce a bug-compatibility flag which is detected
for every OpenSSH version up to and including the current 6.6 - but
not beyond, since https://bugzilla.mindrot.org/show_bug.cgi?id=1818
promises that 6.7 will also implement the new consensus behaviour.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10200 cda61777-01e9-0310-a592-d414129be87e
Fix automatic version numbering in the Unix tarball.

Manfred Schwarb points out that when I moved the autoconf machinery up
from the unix subdirectory to the top level, in r10141, I missed a
couple of lingering $(srcdir)/.. in the make rule for version.o, as a
result of which the automatic checking of the manifest wasn't doing
its thing and tools built from a standard .tar.gz were reporting as
'Unidentified build'.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10201 cda61777-01e9-0310-a592-d414129be87e
Work around a timer leak with GTK 2.4.22 on openSUSE 13.1.

Mihkel Ader reports that on that system, timers apparently aren't
getting auto-destroyed when timer_trigger returns FALSE, so the change
in r10181 has caused GTK PuTTY to gradually allocate more and more
timers and consume more and more CPU as they all keep firing.

As far as I can see, this must surely be a bug in GTK 2 (the docs say
that timers _are_ auto-destroyed when their callback returns false),
and it doesn't seem to happen for me with GTK 2.4.23 on Ubuntu 14.04.
However, I'll try to work around it by _explicitly_ destroying each
old timer before we zero out the variable containing its id.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10202 cda61777-01e9-0310-a592-d414129be87e
Another fix to timer handling.

Robert de Bath points out that failure to remove the timer whose
callback returned FALSE may not have been the cause of runaway timer
explosion; another possibility is that a function called from
timer_trigger()'s call to run_timers() has already set a timer up by
the time run_timers() returns, and then we set another one up on top
of it. Fix that too.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10206 cda61777-01e9-0310-a592-d414129be87e
Preserve truncated parts of terminal lines after a resize.

We now only truncate a termline to the current terminal width if we're
actually going to modify it. As a result, resizing to a narrower
terminal width and then immediately back again, with no terminal
output in between, should restore the previous screen contents. Only
lines that are actually modified while the terminal is narrow (and
scrolling them around doesn't count as modification) should now be
truncated.

This will be a bit nicer for Unix window resizing (since X lacks the
Windows distinction between mid-drag resize events and the ultimate
drag-release, so can't defer the call to term_size until the latter as
we can on Windows), but mostly it's inspired by having played with a
tiling window manager recently and hence realised that in some
environments windows will be resized back and forth without much
control as a side effect of just moving them around - so it's
generally desirable for resizes to be non-destructive.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10208 cda61777-01e9-0310-a592-d414129be87e
Truncate all terminal lines when we clear scrollback.

Now Jacob has reminded me that 'resize-no-truncate' was already on the
wishlist, I notice that it suggested Clear Scrollback should remove
the preserved information off to the right. On the basis that that's
(at least partly) a privacy feature, that seems sensible, so let's do it.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10210 cda61777-01e9-0310-a592-d414129be87e
Fix another crash at KEXINIT time, ahem.

This is the same code I previously fixed for failing to check NULL
pointers coming back from ssh_pkt_getstring if the server's KEXINIT
ended early, leading to an embarrassing segfault in place of a fatal
error message. But I've now also had it pointed out to me that the
fatal error message passes the string as %s, which is inappropriate
because (being read straight out of the middle of an SSH packet) it
isn't necessarily zero-terminated!

This is still just an embarrassing segfault in place of a fatal error
message, and not exploitable as far as I can see, because the string
is passed to a dupprintf, which will either read off the end of
allocated address space and segfault non-exploitably, or else it will
find a NUL after all and carefully allocate enough space to format an
error message containing all of the previous junk. But still, how
embarrassing to have messed up the same code _twice_.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10211 cda61777-01e9-0310-a592-d414129be87e
Fix null dereference in ldisc_configure.

The IDM_RECONF handler unconditionally calls ldisc_configure to
reconfigure the line discipline for the new echo/edit settings, but in
fact ldisc can be NULL if no session is currently active. (Indeed, the
very next line acknowledges this, by testing it for NULL before
calling ldisc_send!) Thanks to Alexander Wong for the report.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10214 cda61777-01e9-0310-a592-d414129be87e
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