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