New hostname-handling functions in misc.c.

These are intended to make it easier to handle strings of the form
"hostname:port" or other colon-separated things including hostnames
(such as the -L and -R command-line option arguments), even though the
hostname part might be a square-bracketed IPv6 address literal
containing colons that have to _not_ be treated as separating the
top-level string components.

Three of these functions have semantics as much like existing C
library functions as I could make them (host_strchr, host_strrchr,
host_strcspn) so that it wouldn't be too error-prone to replace
existing C functions with them at lots of call sites. The fourth
function (host_strduptrim) just strips square brackets off anything
that looks like an IPv6 literal.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10119 cda61777-01e9-0310-a592-d414129be87e
Use the new host_str* functions to improve IPv6 literal support.

I've gone through everywhere we handle host names / addresses (on
command lines, in PuTTY config, in port forwarding, in X display
names, in host key storage...) and tried to make them handle IPv6
literals sensibly, by using the host_str* functions I introduced in my
previous commit. Generally it's now OK to use a bracketed IPv6 literal
anywhere a hostname might have been valid; in a few cases where no
ambiguity exists (e.g. no :port suffix is permitted anyway)
unbracketed IPv6 literals are also acceptable.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10120 cda61777-01e9-0310-a592-d414129be87e
Avoid misidentifying unbracketed IPv6 literals as host:port.

Both GUI PuTTY front ends have a piece of logic whereby a string is
interpreted as host:port if there's _one_ colon in it, but if there's
more than one colon then it's assumed to be an IPv6 literal with no
trailing port number. This permits the PuTTY command line to take
strings such as 'host', 'host:22' or '[::1]:22', but also cope with a
bare v6 literal such as '::1'.

This logic is also required in the two Plink front ends and in the
processing of CONF_loghost for host key indexing in ssh.c, but was
missing in all those places. Add it.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10121 cda61777-01e9-0310-a592-d414129be87e
Support explicit IPv6 source addresses in Windows port forwarding.

There's been a long-standing FIXME in Windows's sk_newlistener which
says that in IPv6 mode, an explicit source address (e.g. from a
command-line option of the form -L srcaddr:12345:dest:22) is ignored.
Now it's honoured if possible.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10122 cda61777-01e9-0310-a592-d414129be87e
Fix a potential crash in ssh_setup_portfwd.

If we search for a colon by computing ptr + host_strcspn(ptr,":"),
then the resulting pointer is always non-NULL, and the 'not found'
condition is not !p but !*p.

This typo could have caused PuTTY to overrun a string, but not in a
security-bug sense because any such string would have to have been
loaded from the configuration rather than received from a hostile
source.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10123 cda61777-01e9-0310-a592-d414129be87e
Don't unconditionally reset scrollback on certain escape sequences.

Handlers for a number of escape sequences, notably including ESC[J and
the sequences that switch to/from the alternate screen, were
unconditionally resetting the scrollback instead of first checking the
'Reset scrollback on display activity' configuration option. I've
added the missing if statements, so now 'Reset scrollback on display
activity' should actually mean what it says.

For example, this would have inconvenienced an mplayer user, who
wouldn't be able to go up and check their scrollback while mplayer was
repeatedly redisplaying its status line, because mplayer uses ESC[J to
erase each version of the status line before printing the next
version.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10125 cda61777-01e9-0310-a592-d414129be87e
Fix warnings when compiling with -DNO_IPV6.

A user pointed out that 'family' was uninitialised in config.c, and
when I tried test-building with -DNO_IPV6 (and the usual -Werror, of
course) some unused variables showed up in uxnet.c too.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10135 cda61777-01e9-0310-a592-d414129be87e
Revert half of r10135, and re-fix properly.

One of my changes in uxnet.c was outside the NO_IPV6 ifdef, and broke
compilation in the normal mode. Revert all changes in that file and
replace with a reference to the 'step' parameter in the no-IPv6
version of the SOCKADDR_FAMILY macro, so that those warnings are
squelched anyway.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10136 cda61777-01e9-0310-a592-d414129be87e
Stop sending release events for mouse wheel 'buttons' in X mouse mode.

On Windows (X mouse reporting of the mouse wheel isn't currently done
by the Unix front end, though I'm shortly about to fix that too) a
mouse wheel event is translated into a virtual button, and we send
both a press and a release of that button to terminal.c, which encodes
both in X mouse reporting escape sequences and passes them on to the
server. This isn't consistent with what xterm does - scroll-wheel
events are encoded _like_ button presses, but differ semantically in
that they don't have matching releases. So we're updating to match
xterm.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10138 cda61777-01e9-0310-a592-d414129be87e
Enable xterm mouse reporting of wheel actions in GTK.

I had somehow missed this completely out of the GTK mouse-button
handling and never noticed until now!

Of course, like any other mouse action, if you want it to be handled
locally rather than passed through then you can hold down Shift.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10139 cda61777-01e9-0310-a592-d414129be87e
Move the Unix configure script up to the top level.

Previously, 'configure' and its assorted machinery lived in the 'unix'
subdir, because that seemed like a clean place to keep it given that
all the other per-platform Makefiles live in their platform
directories. However, this never sat all that happily with autotools,
and even less so now that it likes to have object file pathnames
parallel source file pathnames: if you have Makefile.am refer to
source files outside its subdir as "../terminal.c" and enable
subdir-objects then any out-of-tree build calls the corresponding
object file "../terminal.o" and so your build products mostly end up
at the directory above your build dir! And as of autotools 1.14 my
previous compensatory bodge of prefixing every source file path in
Makefile.am with "$(srcdir)" has stopped working too.

So I'm giving in to necessity, and changing policy by moving the
configure machinery up to the top level of the source tree where
autotools will be less confused by it. This should not be taken as any
indication of the primacy of the Unix port, only of the recalcitrance
of autotools.

Whereas before we had a trivial script called 'configure' at the top
level that invoked unix/configure to effectively do an 'out-of-tree
build' (for make purposes) at the top level of the source tree, we now
have a similar script in unix/configure. So this _should_ make very
little difference: people who were previously running configure from
the top level should still be able to, and likewise people who were
running it from the unix subdir.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10141 cda61777-01e9-0310-a592-d414129be87e
Add the 'subdir-objects' option in the automake makefile.

This rearranges the object files so that they each live alongside
their original source file, instead of all being in the same
directory. To my way of thinking this is a more or less neutral change
(perhaps marginally less tidy), but autotools is apparently beginning
to think it's the One True Way and 1.14 will give a warning if you
don't have it enabled.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10142 cda61777-01e9-0310-a592-d414129be87e
Add the autogenerated empty.h to CLEANFILES.

Colin Watson points out that it's untidy to create it with the
makefile but not clean it up again in the same way.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10143 cda61777-01e9-0310-a592-d414129be87e
Add some assertions in sshzlib.c.

gcc 4.8 compiling with -O3 gives a new warning about the access to
st->pending at the top of lz77_compress, because for some reason it
thinks there's an out-of-bounds array access there (or perhaps just a
potential one, I'm not really sure which side -Warray-bounds is erring
on). Add an assertion reassuring it that st->npending can't get bigger
than the size of st->pending at the site it's complaining about, and a
second one at the site where st->npending is increased (just in case
my analysis of why it can't happen was wrong!). Also add a comment
explaining the assertions.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10144 cda61777-01e9-0310-a592-d414129be87e
Add a missing bn_restore_invariant in RSA blinding code.

We were inventing a random number by starting with a long zero bignum
and then setting bits at random, which left an opportunity for the
result to be a non-normalised representation (with a leading zero
word) and hence fail an assertion in bignum_cmp.


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