Performance: cache character widths returned from Pango.

Profiling reveals that pterm in Pango rendering mode uses an absurd
amount of CPU when it's not even actually _drawing_ the text, because
of all the calls to pango_layout_get_pixel_extents() while
pangofont_draw_text tries to work out which characters it can safely
draw as part of a long string. Caching the results speeds things up
greatly.

Fix an arithmetic error in the X font downloader cache.

If you're trying to arrange that an array size is large enough for
element n to exist, and you also want to round it up to the next
multiple of 0x100, you must set the size to (n + 0x100) & ~0xFF, and
not (n + 0xFF) & ~0xFF. Put another way, the number you have to round
up is not n, but the minimum size n+1 that causes array[n] to exist.

'pterm --display' should set $DISPLAY inside the terminal.

If you open a pterm on a different display via the --display
command-line option rather than by setting $DISPLAY, I think (and
other terminals seem to agree) that it's sensible to set $DISPLAY
anyway for processes running inside the terminal.

In GTK3, use the new GtkColorChooserDialog.

This replaces the old GtkColorSelectionDialog, and has the convenience
advantage that the actual chooser (with all the 'set colour', 'get
colour' methods) and the containing dialog box are now the same object
implementing multiple interfaces, so I don't keep having to call 'get
me the underlying chooser for this dialog' accessors. Also you now
hook into both the OK and Cancel buttons (and all other response
codes) at the same time with a single event.

In GTK3, unifontsel should use GtkGrid, not GtkTable.

GtkTable is deprecated; the way of the future is GtkGrid, in which you
don't have to specify the number of rows/columns in advance (it's
worked out dynamically by observing what row/column numbers you
actually attached anything to), and also you handle expansion
behaviour by setting the "hexpand", "vexpand" or "expand" properties
on the child widgets rather than setting flags in the container.

Stop using GTK3-deprecated gdk_window_set_background().

We now have to use gdk_window_set_background_rgba(), having first set
up an appropriate GdkRGBA structure.

Stop using GTK3-deprecated gdk_get_display().

The new way is gdk_display_get_name(gdk_display_get_default()), which
returns a const char * rather than a char *, so I've also had to
fiddle with the prototype and call sites of get_x_display().

(Also included gtkcompat.h into uxputty.c, since that wanted to call
gdk_get_display() but didn't previously include it.)

Provide #defines for GTK3-deprecated gtk_{h,v}foo_new().

In GTK3, GtkBox, GtkScrollbar and GtkSeparator are all single classes
with a GtkOrientation parameter, whereas in GTK2 the horizontal and
vertical versions were trivial subclasses of them. Hence, the old
constructors are now deprecated, but _only_ the constructors are
affected, since after constructing one you always used methods of the
superclass on it anyway.

Rather than faff about with an ifdef at every call site, I've just put
some wrapper macros in gtkcompat.h to make it easy to keep this code
similar between all supported GTK versions.

Avoid deprecated gtk_cell_renderer_get_size in GTK3.

gtk_cell_renderer_get_preferred_size() is the new way to do it.

Stop using deprecated GTK_STOCK_* in GTK3.

According to the GTK3 docs, we're now supposed to use fixed label
strings instead.

Make unifontsel_deselect() clear the preview pane.

In the case where we deselect the previously selected font (e.g.
because we've just changed the filter settings to remove it from the
list), we were leaving the preview pane in its previous state, which
is fine in GTK2 when it just carries on displaying the last thing
drawn to the backing pixmap but goes wrong in GTK3 where we still have
to actually respond to draw events.

But it makes more conceptual sense anyway to actually empty the
preview pane when no font is selected, so now we do that. So now
unifontsel_draw_preview_text() is called from unifontsel_deselect(),
and also the preview-drawing code will still draw the background
rectangle regardless of whether font != NULL.

Fix crash in GTK3 when unifontsel filter settings change.

The call to gtk_list_store_clear() in unifontsel_setup_familylist()
was causing a call to family_changed() via the GTK signal system,
which didn't happen in GTK2. family_changed() in turn was calling
unifontsel_select_font(), which got confused when the tree model
didn't match reality, and tried to access a bogus tree iterator.

This is easily fixed by using the existing fs->inhibit_response flag,
which prevents us responding to GTK events when we know they were
generated by our own fiddling about with the data; it's just that we
never needed to set it in unifontsel_setup_familylist() before.

Also, added a check of the return value from the key get_iter call in
unifontsel_select_font(), so that it'll at least fail an assertion
rather than actually trying to access bogus memory. But that operation
_should_ still always succeed, and if it doesn't, it's probably a sign
that we need another use of fs->inhibit_response.

Fix GTK3 size calculations in unifontsel_new.

It turns out that in GTK3, if you instantiate a GtkLabel and
immediately try to find out its preferred size, you get back zero for
both dimensions. Presumably none of that gets figured out properly
until the widget is displayed, or some such.

However, you can retrieve the PangoLayout from the label immediately
and ask Pango for the dimensions of that. That seems like a bit of a
bodge, but it works! The GTK3 unifont selector now comes out with all
the interface elements in sensible sizes - in particular, the preview
drawing area now has non-zero height.

In GTK3, don't use the "has-separator" GtkDialog property.

It doesn't exist any more, so the attempt to set it was generating an
annoying runtime warning message.

Use GTK3's method of setting GtkEntry min width.

The config box setup code wants a lot of very narrow edit boxes, so it
decreases their minimum width from the GTK default of 150 pixels. In
GTK 3, we have to do this using gtk_entry_set_width_chars() rather
than gtk_widget_set_size_request() as we were previously using, or it
won't work.

This change by itself seems to restore the GTK3 config box to a
sensible layout, in spite of the fact that my Columns layout class is
still doing all its size allocation the GTK2 way, with no attention
paid to the shiny new GTK3 height-for-width system.

Remove arbitrary limit SSH2_MKKEY_ITERS.

Tim Kosse points out that we now support some combinations of crypto
primitives which break the hardwired assumption that two blocks of
hash output from the session-key derivation algorithm are sufficient
to key every cipher and MAC in the system.

So now ssh2_mkkey is given the desired key length, and performs as
many iterations as necessary.

Add a key-length field to 'struct ssh_mac'.

The key derivation code has been assuming (though non-critically, as
it happens) that the size of the MAC output is the same as the size of
the MAC key. That isn't even a good assumption for the HMAC family,
due to HMAC-SHA1-96 and also the bug-compatible versions of HMAC-SHA1
that only use 16 bytes of key material; so now we have an explicit
key-length field separate from the MAC-length field.

Add copy and free methods to 'struct ssh_hash'.

This permits a hash state to be cloned in the middle of being used, so
that multiple strings with the same prefix can be hashed without
having to repeat all the computation over the prefix.

Having done that, we'll also sometimes need to free a hash state that
we aren't generating actual hash output from, so we need a free method
as well.

New test output file, checking all display-relevant stuff.

This is the test file I wish I'd had while I was rewriting the
text-drawing function this week :-) Better late than never.

GTK3 port: add '--with-gtk=3' to the configure script.

After the last few changes, the whole codebase now compiles and links
successfully against GTK3, and I can run an experimental pterm. The
config box and font selector look ugly, but the basics all seem to
work.

In order to compile at all, I had to manually bodge in the extra
compile flag -Wno-deprecated-declarations. My plan is to fix all the
uses of deprecated things, and then remove that flag.

I've made GTK3 the second choice, after GTK2 but before GTK1. GTK2 is
the only GTK version that produces a completely sensible build (partly
because the GTK3 port is visibly unfinished, and mostly because its
server-side font handling is just too slow), so it remains the first
choice.

GTK3 port: condition out all uses of GdkColormap.

The entire concept has gone away in GTK3, which assumes that everyone
is now using modern true-colour video modes and so there's no longer
any reason you shouldn't just casually make up any RGB triple you like
without bothering to ask the display system's permission.

GTK3 port: respell GDK_WINDOW_XWINDOW / GDK_DRAWABLE_XID.

GDK3 now spells both of those as GDK_WINDOW_XID. (Of course 'drawable'
is no longer a relevant concept in GDK3, since pixmaps are no longer
supported and so all drawables are just windows.) We keep backwards
compatibility, of course.

GTK3 port: replace size_request in the Columns layout class.

It's been replaced by a new pair of methods get_preferred_width and
get_preferred_height. For the moment, I've followed the porting
guide's suggestion of keeping the old size_request function as an
underlying implementation and having each of those methods just return
one of its outputs. The results are ugly, but it'll compile and run,
which is a start.

GTK3 port: use gdk_device_grab() in gtkask.c.

This replaces the old gdk_keyboard_grab(), and is what a GTK3 app has
to use for grabbing the keyboard away from all other X clients.

GTK3 port: support the new "draw" signal.

This replaces GTK 1/2's "expose_event", and provides a ready-made
cairo_t to do the drawing with. My previous work has already separated
all constructions of a cairo_t from the subsequent drawing with it, so
the new draw event handlers just have to call the latter without the
former.

Reimplement GTK uxsel_input_add using GIOChannel.

This is the new recommended approach since gdk_input_{add,remove} were
deprecated (and, honestly, seems a lot more sensible - why on earth
would those functions have lived in *GDK* of all places?). The old
implementation is preserved under ifdef for GTK1.

This was the last of the GDK deprecated functions to go! So GTK PuTTY
now compiles cleanly with -DGDK_DISABLE_DEPRECATED in addition to all
the other precautionary flags (though if you do that, you disable GDK
rendering, which greatly slows down server-side font handling). This
completes the GTK2-compatible preparation phase of the GTK 3 migration
guide.

Change uxsel_input_add's return type from int to pointer.

In case a front end needs to store more than an integer id to be
returned to uxsel_input_remove, we now return a pointer to a
frontend-defined structure.

Use gtk_window_set_icon() where available.

GTK is deprecating the use of gdk_window_set_icon(), in favour of a
method that doesn't have to drop down to the GDK level at all (and
also doesn't use a pixmap). No reason not to use that instead.

Remove an outdated comment.

I've just noticed the comment in gtkfont.c that said wouldn't it be
nice to find a way to avoid the GDK pixmap-stretching code when using
Pango fonts. We now do support this, but we support it in gtkwin.c
rather than gtkfont.c - because we do it using a Cairo transformation
matrix, so it still takes place at the level above Pango rather than
in Pango proper. (I never did find out whether Pango itself included
facilities to arbitrarily stretch a font.)

Hence, this comment is useless now. Discard.

Replace deprecated GDK_DISPLAY() with modern facilities.

We still don't actually support more than one X display active at
once, so it's sufficient to replace every call to that macro with
GDK_DISPLAY_XDISPLAY(gdk_display_get_default()).

Make the use of server-side backing pixmaps in GTK optional.

We won't be able to use them in GTK3, or when compiling with GTK2 and
-DGDK_DISABLE_DEPRECATED.

This applies to the one we use for the main terminal window, and also
the small one we use for the preview pane in the unified font selector.

Saw unifontsel_draw_preview_text() in half.

Now it's got an inner half that does actual drawing given a draw
context, and an outer half that sets up and tears down the draw
context. Sooner or later the inner half will need calling
independently of the outer, because GTK3's draw event will provide a
ready-made cairo_t.

Call draw_stretch_before *after* setting up the clip region.

A small bug in yesterday's work: since in Cairo mode
draw_stretch_before changes the transformation matrix, if we do it
before calling draw_clip then the clip region will be interpreted in
the transformed coordinates.

This caused a subtle display bug in yesterday's commit: drawing one
half of double-height text would have drawn _both_ halves of it on to
the window's backing pixmap, but only copied the correct half on to
the window proper - but the overdrawing on the pixmap would have shown
up if the window was hidden and re-exposed.

Withdraw the horrible bodge in make_mouse_ptr().

We were previously building our own mouse pointers out of pixmaps,
having first drawn characters from the X server standard font 'cursor'
on to those pixmaps, giving an effect almost exactly the same as just
calling gdk_cursor_new(some constant) except that we got to choose the
foreground and background colours of the resulting pointers.

But it's not clear why we needed to do that! In both GTK1 and GTK2 as
of my current testing, the standard colours appear to be just what I
wanted anyway (white pointer with black outline). The previous
implementation (and commit comment) was written in 2002, so perhaps it
was working around a GTK1 bug of the time.

So I've removed it completely, and replaced it with simple calls to
gdk_cursor_new  (plus a workaround for GTK1's lack of GDK_BLANK_CURSOR,
but that's still much simpler than the previous code). If anyone does
report a colour problem, I may have to go back to doing something
clever, but if I can possibly arrange it, I'll want to do it by some
other technique, probably (as suggested in a comment in the previous
implementation) getting the underlying X cursor id and calling
XRecolorCursor.

Refactor the GTK drawing system to do both GDK and Cairo.

We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.

X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.

One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.

(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)

Stop multifont fallback from crashing in GTK1.

I was tacitly assuming that mfont->fallback would always be non-NULL,
which is true in a world containing Pango, but untrue in GTK1 when
Pango isn't there. In that situation we fall back to just omitting the
characters that would be displayed in the fallback font, on the
grounds that that's better than dereferencing through a NULL vtable.

Close file descriptor in test main().

Some static analyzers are complaining about it.

Fix signature of platform_new_connection.

The hostname is a const char *.

Use DWORD as length argument for RegQueryValueEx.

Cast return value of ShellExecute to INT_PTR.

ShellExecute returns HINSTANCE which is a typedef for void*. Cast the
return value to INT_PTR instead of int to avoid truncation on 64bit
builds.

Use INT_PTR not int to store result of DialogBoxParam.

DLGPROC callbacks should return INT_PTR.

The Windows headers define the return type of DLGPROC as INT_PTR which
on 64bit Windows has a different size than int.

Fix type of third argument to AppendMenu

We are passing pointers as third argument to AppendMenu. Do not
truncate them to UINT, use UINT_PTR instead which has the required
size on 64bit Windows.

Fix type of 4th argument to WinHelp

We're passing a pointer as 4th argument to WinHelp. Do not cast it to
DWORD which would truncate the pointer. Instead use UINT_PTR as that
is what WinHelp expects.

Cast pointers to uintptr_t instead of unsigned {long,int}.

On 64bit Windows, pointers are 64bit whereas both unsigned long and
unsigned int are 32bit. Using uintptr_t avoids truncation.

Fix warning about mismatched constness.

Use correct type to print Windows error codes.

GetLastError returns DWORD. To print it, convert it to unsigned int
and use the %u format specifier.

Do not re-define SECURITY_WIN32 if already defined.

Some toolchains have SECURITY_WIN32 defined by default.

Make manifest files work with 64bit builds of PuTTY.

Otherwise we would get 0xc000007b error when trying to start a 64bit
PuTTY Windows binary.

Detect end of string in fingerprint alignment.

This prevents writing past the end of the buffer should
ssh2_fingerprint ever return a fingerprint not containing a colon.

Fix  __uint128_t compile error on MinGW.

MinGW has __uint128_t, but not __uint64_t.

Remove an unused variable.

Remove an unused variable.

Fix warning about uninitialized variable.

Some MinGW versions do not know that assert(0) never returns. This
change also handles the case of building with NDEBUG.

Remove unused variable.

Fix warning about missing return in ssh2_kexinit_addalg

Fix a format string vulnerability if MALLOC_LOG is set.

Fix format string vulnerabilities.

Reported by Jong-Gwon Kim. Also fixes a few memory leaks in the
process.

Add a FAQ for 'checksum mismatch' reports.

The aim is to try to reduce the incidence of the two least helpful
classes of those reports: the ones which have just got mismatched
checksum files, and the ones which don't tell us the information that
would help.

Fix compile failure.

I'm sure I removed that 'return 0' at some point! But I must have made
a git error which excluded it from the commit I actually pushed, ahem.

GTK 3 prep: write a replacement for gtk_quit_add().

GTK 2 has deprecated it and provided no replacement; a bug tracker
entry I found on the subject suggested that it was functionality that
didn't really belong in GTK, and glib ought to provide a replacement
instead, which would be a perfectly fine thing to suggest if they had
waited for glib to get round to doing so *before* throwing out a
function people were actually using. Sigh.

Anyway, it turns out that subsidiary invocations of gtk_main() don't
happen inside GTK as far as I can see, so all I need to do is to make
sure my own invocations of gtk_main() are followed by a cleanup
function which runs any quit functions that I've registered.

That was the last deprecated GTK function, so we now build cleanly
with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits
ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that
has migrating to Cairo drawing as a prerequisite.)

Use gtkcompat.h to slim down a few ifdefs.

Now that I've got a general place to centralise handling of at least
the simple differences between GTK 1 and 2, I should use it wherever
possible. So this commit removes just a small number of ifdefs which
are either obsoleted by definitions already in gtkcompat.h (like
set_size_request vs set_usize), or can easily be replaced by adding
another (e.g. gtk_color_selection_set_has_opacity_control).

GTK 3 prep: stop using *nearly* all GTK deprecated functions.

Building with -DGTK_DISABLE_DEPRECATED, we now suffer only one compile
failure, for the use of gtk_quit_add() in idle_toplevel_callback_func.
That function is apparently removed with no replacement in GTK 3, so
I'll need to find a completely different approach to getting toplevel
callbacks to run only in the outermost instance of gtk_main().

Also, this change doesn't do anything about the use of *GDK*
deprecated functions, because those include the entire family of
old-style drawing functions - i.e. the only way to build cleanly with
-DGDK_DISABLE_DEPRECATED will be to switch to Cairo drawing.

Switch to using gtk_window_parse_geometry in GTK 2.

On GTK versions where it's available, this is a much nicer way of
handling the -geometry command-line option, since not only do we get
all the faffing about with gravity for free, it also automatically
sets the user-position WM hints.

GTK 3 prep: replace GtkFileSelection with GtkFileChooserDialog.

I've put in a special #define to control this selection, in case I
decide that for reasons of taste I'd prefer to switch back to
GtkFileSelection in GTK2 which supports both!

GTK 3 prep: use gtk_color_selection_get_current_color().

Replaces the deprecated gtk_color_selection_set_color() which took an
array of four doubles (RGBA), and instead takes a 'GdkColor' struct
containing four 16-bit integers.

For GTK1, we still have to retain the original version.

GTK 3 prep: use the glib names for base object types.

All the things like GtkType, GtkObject, gtk_signal_connect and so on
should now consistently have the new-style glib names like GType,
GObject, g_signal_connect, etc.

Allow direct use of X11 to be conditionally compiled out.

A major aim of introducing GTK 3 support is to permit compiling for
non-X11 platforms that GTK 3 supports, so I'm going to need to be able
to build as a pure GTK application with no use of X11 internals.
Naturally, I don't intend to stop supporting the hybrid GTK+X11 mode
in which X server-side bitmap fonts are available.

Use of X11 can be removed by compiling with -DNOT_X_WINDOWS. That's
the same compatibility flag that was already used by the unfinished OS
X port to disable the X-specific parts of uxpty.c; now it just applies
to more source files.

(There's no 'configure' option to set this flag at present. I haven't
worked out whether we'll need one yet.)

GTK 3 prep: use GDK_KEY_<keyname> constants, not GDK_<keyname>.

GTK 2 doesn't _documentedly_ provide a helpful compile option to let
us check this one in advance of GTK 3, but you can fake one anyway by
compiling with -D__GDK_KEYSYMS_COMPAT_H__, so that gdkkeysyms-compat.h
will believe that it's already been included :-) We now build cleanly
under GTK 2 with that predefine.

GTK 3 prep: use accessor functions for object data fields.

We now build cleanly in GTK2 with -DGSEAL_ENABLE.

GTK 3 prep: do not include individual GTK/GDK headers.

This is the first of several cleanup steps recommended by the GTK 2->3
migration guide.

I intend to begin work towards compatibility with GTK 3, but without
breaking GTK 2 and even GTK 1 compatibility in the process; GTK 2 is
still useful to _me_ (not least because it permits much easier support
of old-style server-side X11 fonts), and I recall hearing a rumour
that at least one kind of strange system can only run GTK 1, so for
the moment I don't intend to stop supporting either.

Including gdkkeysyms.h is not optional in GTK 2, because gdk.h does
not include it. In GTK 3 it does, so we don't explicitly reinclude it
ourselves.

We now build cleanly in GTK2 with -DGTK_DISABLE_SINGLE_INCLUDES. (But
that doesn't say much, because we did already! Apparently gdkkeysyms.h
was a special case which that #define didn't forbid.)

Make gtkask.c compile under GTK 1.

This is less than ideal - passphrase input now happens in ISO 8859-1,
and the passphrase prompt window is neither centred nor always-on-top.
But it basically works, and restores bare-minimum GTK 1 support to the
codebase as a whole.

New formatting directive in logfile naming: &P for port number.

Users have requested this from time to time, for distinguishing log
file names when there's more than one SSH server running on different
ports of the same host. Since we do take account of that possibility
in other areas (e.g. we cache host keys indexed by (host,port) rather
than just host), it doesn't seem unreasonable to do so here too.

Work around a failure in Windows 10 jump lists.

We've had several reports that launching saved sessions from the
Windows 10 jump list fails; Changyu Li reports that this is because we
create those IShellLink objects with a command line string starting
with @, and in Windows 10 that causes the SetArguments method to
silently do the wrong thing.

New 'contrib' script to sort out email-corrupted packet logs.

If a PuTTY SSH packet log has gone through line-wrapping at 72
columns, destroying the long lines of the packet hex dumps, then this
script will reconstitute it as best it can, by reconstructing the
ASCII section at the end of the dump from the (hopefully) undamaged
hex part, and using that to spot wrapped lines and remove the
subsequent debris.

Don't try to load GSSAPI libs unless we'll use them.

A user reports that in a particular situation one of the calls to
LoadLibrary from wingss.c has unwanted side effects, and points out
that this happens even when the saved session has GSSAPI disabled. So
I've evaluated as much as possible of the condition under which we
check the results of GSS library loading, and deferred the library
loading itself until after that condition says we even care about the
results.

Fix braino in gtkask.c loop conditions.

If you're counting up to ms_limit in steps of ms_step, it's silly to
add ms_step at the end of the loop body _and_ increment the loop
variable by 1 in the loop header. I must have been half asleep.

Handle the VK_PACKET virtual key code.

This is generated in response to the SendInput() Windows API call, if
that in turn is passed an KEYBDINPUT structure with KEYEVENTF_UNICODE
set. That method of input generation is used by programs such as
'WinCompose' to send an arbitrary Unicode character as if it had been
typed at the keyboard, even if the keyboard doesn't actually provide a
key for it.

Like VK_PROCESSKEY, this key code is an exception to our usual policy
of manually translating keystrokes: we handle it by calling
TranslateMessage, to get back the Unicode character it contains as a
WM_CHAR message.

(If that Unicode character in turn is outside the BMP, it may come
back as a pair of WM_CHARs in succession containing UTF-16 surrogates;
if so, that's OK, because the new Unicode WM_CHAR handler can cope.)

Turn the Windows PuTTY main window into a Unicode window.

This causes WM_CHAR messages sent to us to have a wParam containing a
16-bit value encoded in UTF-16, rather than an 8-bit value encoded in
the system code page.

As far as I can tell, there aren't many other knock-on effects - e.g.
you can still interact with the window using ordinary char-based API
functions such as SetWindowText, and the Windows API will do the
necessary conversions behind the scenes. However, even so, I'm half
expecting some sort of unforeseen bug to show up as a result of this.

New centralised helper function dup_mb_to_wc().

PuTTY's main mb_to_wc() function is all very well for embedding in
fiddly data pipelines, but for the simple job of turning a C string
into a C wide string, really I want something much more like
dupprintf. So here is one.

I've had to put it in a new separate source file miscucs.c rather than
throwing it into misc.c, because misc.c is linked into tools that
don't also include a module providing the internal Unicode API (winucs
or uxucs). The new miscucs.c appears only in Unicode-using tools.

Post-0.65 release checklist updates.

The -F option is no longer needed to bob in this situation; that
hasn't been the directory I keep release announcements in for a long
time; the Docs page needs adjusting for pre-release retirement as well
as the Downloads page.

Add a commentary assertion in config dialog setup.

Coverity complained that some paths through the loop in the
WM_INITDIALOG handler might leave firstpath==NULL. In fact this can't
happen because the input data to that loop is largely static and we
know what it looks like, but it doesn't seem unreasonable to add an
assertion anyway, to keep static checkers happy and as an explanatory
quasi-comment for humans.

Merge tag '0.65'

Bump version number for 0.65 release.

Merge branch 'pre-0.65'

When PSFTP exits in batch mode due to a command failure, set exit status != 0.

There are possibly other circumstances when PSFTP should also return
failure, but that one seems particularly obvious.

When encrypting packet length with ChaCha20, treat sequence number as 32 bits.

While ChaCha20 takes a 64-bit nonce, SSH-2 defines the message
sequence number to wrap at 2^32 and OpenSSH stores it in a u_int32_t,
so the upper 32 bits should always be zero.  PuTTY was getting this
wrong, and either using an incorrect nonce or causing GCC to complain
about an invalid shift, depending on the size of "unsigned long".  Now
I think it gets it right.

Merge branch 'pre-0.65'

Inaugural merge from branch 'pre-0.65'.

This is a null merge (done with '-s ours'), not changing the code on
master at all: it just adds an ancestor relationship so that any fresh
commits on pre-0.65 can be cleanly merged to here in the obvious way.

Fix a crash when connection-sharing during userauth.

If a sharing downstream disconnected while we were still in userauth
(probably by deliberate user action, since such a downstream would
have just been sitting there waiting for upstream to be ready for it)
then we could crash by attempting to count234(ssh->channels) before
the ssh->channels tree had been set up in the first place.

A simple null-pointer check fixes it. Thanks to Antti Seppanen for the
report.

Fix a mismerge in kex null-pointer checks.

I removed a vital line of code while fixing the merge conflicts when
cherry-picking 1eb578a488a71284d6b18e46df301e54805f2c35 as
26fe1e26c0f7ab42440332882295667d4a0ac500, causing Diffie-Hellman key
exchange to be completely broken because the server's host key was
never constructed to verify the signature with. Reinstate it.

Fix accidental dependence on Windows API quirk in config box.

Our config boxes are constructed using the CreateDialog() API
function, rather than the modal DialogBox(). CreateDialog() is not
that different from CreateWindow(), so windows created with it don't
appear on the screen automatically; MSDN says that they must be shown
via ShowWindow(), just like non-dialog windows have to be. But we
weren't doing that at any point!

So how was our config box ever getting displayed at all? Apparently by
sheer chance, it turns out. The handler for a selection change in the
tree view, which has to delete a whole panel of controls and creates a
different set, surrounds that procedure with some WM_SETREDRAW calls
and an InvalidateRect(), to prevent flicker while lots of changes were
being made. And the creation of the _first_ panelful of controls, at
dialog box setup, was done by simply selecting an item in the treeview
and expecting that handler to be recursively called. And it appears
that calling WM_SETREDRAW(TRUE) and then InvalidateRect was
undocumentedly having an effect equivalent to the ShowWindow() we
should have called, so that we never noticed the latter was missing.

But a recent Vista update (all reports implicate KB3057839) has caused
that not to work any more: on an updated Vista machine, in some
desktop configurations, it seems that any attempt to fiddle with
WM_SETREDRAW during dialog setup can leave the dialog box in a really
unhelpful invisible state - the window is _physically there_ (you can
see its taskbar entry, and the mouse pointer changes as you move over
where its edit boxes are), but 100% transparent.

So now we're doing something a bit more sensible. The first panelful
of controls is created directly by the WM_INITDIALOG handler, rather
than recursing into code that wasn't really designed to run at setup
time. To be on the safe side, that handler for treeview selection
change is also disabled until the WM_INITDIALOG handler has finished
(like we already did with the WM_COMMAND handler), so that we can be
sure of not accidentally messing about with WM_SETREDRAW at all during
setup. And at the end of setup, we show the window in the sensible
way, by a docs-approved call to ShowWindow().

This appears (on the one machine I've so far tested it on) to fix the
Vista invisible-window issue, and also it should be more API-compliant
and hence safer in future.

(cherry picked from commit 6163710f043fb58fc80f6b45c14a92f7036bde75)

Add missing null-pointer checks in key exchange.

Assorted calls to ssh_pkt_getstring in handling the later parts of key
exchange (post-KEXINIT) were not checked for NULL afterwards, so that
a variety of badly formatted key exchange packets would cause a crash
rather than a sensible error message.

None of these is an exploitable vulnerability - the server can only
force a clean null-deref crash, not an access to actually interesting
memory.

Thanks to '3unnym00n' for pointing out one of these, causing me to
find all the rest of them too.

(cherry picked from commit 1eb578a488a71284d6b18e46df301e54805f2c35)

Conflicts:
ssh.c

Cherry-picker's notes: the main conflict arose because the original
commit also made fixes to the ECDH branch of the big key exchange if
statement, which doesn't exist on this branch. Also there was a minor
and purely textual conflict, when an error check was added right next
to a function call that had acquired an extra parameter on master.

Use 64-bit BignumInt wherever __uint128_t is available.

gcc and clang both provide a type called __uint128_t when compiling
for 64-bit targets, code-generated more or less similarly to the way
64-bit long longs are handled on 32-bit targets (spanning two
registers, using ADD/ADC, that sort of thing). Where this is available
(and they also provide a handy macro to make it easy to detect), we
should obviously use it, so that we can handle bignums a larger chunk
at a time and make use of the full width of the hardware's multiplier.
Preliminary benchmarking using 'testbn' suggests a factor of about 2.5
improvement.

I've added the new possibility to the ifdefs in sshbn.h, and also
re-run contrib/make1305.py to generate a set of variants of the
poly1305 arithmetic for the new size of BignumInt.

(cherry picked from commit f8b27925eee6a37df107a7cd2e718e997a52516e)

Conflicts:
sshccp.c

Cherry-picker's notes: the conflict arose because the original commit
also added new 64-bit autogenerated forms of dedicated Poly1305
arithmetic, which doesn't exist on this branch.

Improve integer-type hygiene in bignum code.

In many places I was using an 'unsigned int', or an implicit int by
virtue of writing an undecorated integer literal, where what was
really wanted was a BignumInt. In particular, this substitution breaks
in any situation where BignumInt is _larger_ than unsigned - which it
is shortly about to be.

(cherry picked from commit e28b35b0a39de28fa2f71aa78071d1ad62deaceb)

Conflicts:
sshbn.c
sshccp.c

Cherry-picker's notes: the conflicts were because the original commit
also modified new code (sshccp.c for dedicated Poly1305 arithmetic
routines, sshbn.c for a few bignum functions introduced on trunk for
various pieces of new crypto) which doesn't exist on this branch.

Provide a stub random_byte() to make 'testbn' compile again.

The function bignum_random_in_range() is new to sshbn.c since I last
tried to run the bignum test code.

(cherry picked from commit 0aa92c8fa2bee2e4c0082adcc9f06ead24989698)

Don't try sending on sharing channels.

The final main loop in do_ssh2_authconn will sometimes loop over all
currently open channels calling ssh2_try_send_and_unthrottle. If the
channel is a sharing one, however, that will reference fields of the
channel structure like 'remwindow', which were never initialised in
the first place (thanks, valgrind). Fix by excluding CHAN_SHARING
channels from that loop.

(cherry picked from commit 7366fde1d4831dcc701bc31e9de1113636fba1c5)

Clean up downstream sockets when upstream loses its SSH connection.

If the real SSH connection goes away and we call sharestate_free with
downstreams still active, then that in turn calls share_connstate_free
on all those downstreams, freeing the things their sockets are using
as Plugs but not actually closing the sockets, so further data coming
in from downstream gives rise to a use-after-free bug.

(Thanks to Timothe Litt for a great deal of help debugging this.)

(cherry picked from commit 0b2f283622603242d8bce295e42342649aebbb97)

Move BignumInt definitions into a header file.

This allows files other than sshbn.c to work with the primitives
necessary to build multi-word arithmetic functions satisfying all of
PuTTY's portability constraints.

(cherry picked from commit 2c60070aad2d959a9e7e850523352c23c6aa7009)

Cherry-picker's notes: required on this branch because it's a
dependency of f8b27925eee6a37df107a7cd2e718e997a52516e which we want.

Commit my replacement Windows I-beam mouse pointer.

Installing this systemwide as the Windows text selection cursor is a
workaround for 'black-pointer'. It's a white I-beam with a one-pixel
black outline around it, so it should be visible on any background
colour. (I suppose that a backdrop of tightly packed I-beams looking
just like it might successfully hide it, but that's unlikely :-)

I constructed this some years ago for personal use; I needed it again
this week and had to go and recover it from a backup of a defunct
system, which made me think I really ought to check it in somewhere,
and this 'contrib' directory seems like the ideal place.

(cherry picked from commit e222db14ff28482b668baf7c21bb415f29e6df58)