simon-git: putty (master): Simon Tatham

Thu May 31 18:52:51 BST 2018

TL;DR:
  37aca55 Makefile.clangcl: permit building for Windows on Arm.
  421d772 Mention CPU architecture in Windows build info.
  a4d82d9 Add Arm Windows builds to the main build script.
  2cf07bb Buildscr: parallelise all the 'make' commands.
  619f672 Move null pointer checks to before FROMFIELD.
  108e19e Install ssh-connection packet handlers synchronously.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-05-31 18:52:51

commit 37aca556cece1d6ab7f1405c92f157cdb65d8555
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=37aca556cece1d6ab7f1405c92f157cdb65d8555;hp=d659507d93da599281f6244c914eda9a52e2097b
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed May 30 19:10:07 2018 +0100

    Makefile.clangcl: permit building for Windows on Arm.

    Now we don't have to worry about which windres we're using (or whether
    another target architecture's windres will do just as well), this is
    very easy - just test for a couple of extra values of $(Platform).

    To build on Arm with VS2017 includes and libraries, various blog posts
    and websites explain that you have to #define a cumbersome macro
    called _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE, without which the
    headers will #error at you. But if you do that, then everything seems
    to compile fine and I actually tested it on an Arm Windows machine
    today.

    Also, I had to disable stack protection (/GS-), because clang-cl
    doesn't yet support the particular form of it for which the VS2017 Arm
    C library provides the runtime support. Unfortunate in a security
    application, of course, but there we go.

 mkfiles.pl | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

commit 421d772e27a61f405e562175b19e7c4765a29d9d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=421d772e27a61f405e562175b19e7c4765a29d9d;hp=37aca556cece1d6ab7f1405c92f157cdb65d8555
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 18:12:01 2018 +0100

    Mention CPU architecture in Windows build info.

    Apparently Windows on Arm has an emulator that lets it run x86
    binaries without it being obvious, which could get confusing when
    people start reporting what version of what they're running where.
    (Indeed, it might get confusing for _me_ during early testing.) So now
    the Windows builds explicitly state 'x86' or 'Arm' as well as 32- or
    64-bit.

 windows/winstuff.h | 6 ++++++
 1 file changed, 6 insertions(+)

commit a4d82d90a81ebd159b04fb4620a0a338eea6a825
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=a4d82d90a81ebd159b04fb4620a0a338eea6a825;hp=421d772e27a61f405e562175b19e7c4765a29d9d
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 18:19:23 2018 +0100

    Add Arm Windows builds to the main build script.

    I build both 32- and 64-bit versions of the .exe files, code-sign
    them, and create the same .zip file as I do for x86 Windows. I don't
    yet have a method of building Arm MSI installers, though.

 Buildscr | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

commit 2cf07bb8fe6fb9cee1762b4e87837320b07b69bc
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=2cf07bb8fe6fb9cee1762b4e87837320b07b69bc;hp=a4d82d90a81ebd159b04fb4620a0a338eea6a825
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 18:11:16 2018 +0100

    Buildscr: parallelise all the 'make' commands.

    Now we're building four rather than two sets of Windows binaries, the
    build time has gone up rather painfully. I've just added a feature to
    bob where it will invent a sensible value to use in 'make -j' and the
    like, so let's start using it.

 Buildscr | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

commit 619f6722d8ed7fd7d5a115ee4c268a185bd350a0
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=619f6722d8ed7fd7d5a115ee4c268a185bd350a0;hp=2cf07bb8fe6fb9cee1762b4e87837320b07b69bc
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 18:32:09 2018 +0100

    Move null pointer checks to before FROMFIELD.

    This fixes an oversight in commit 0fc2d3b45: if a key creation
    function returns a null 'ssh_key *', then adjusting the pointer's
    address using FROMFIELD is a mistake, both in technical C terms
    (undefined behaviour) and practically speaking because it will foil
    the subsequent check against NULL. Instead, if we're going to check a
    pointer against NULL, we must do it _before_ applying this kind of
    address-adjusting type conversion.

 sshdss.c | 16 ++++++++++------
 sshecc.c | 23 ++++++++++++++---------
 sshrsa.c | 24 ++++++++++++++++--------
 3 files changed, 40 insertions(+), 23 deletions(-)

commit 108e19e73cf7dad9bfd8732784ced04d97f827d9
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=108e19e73cf7dad9bfd8732784ced04d97f827d9;hp=619f6722d8ed7fd7d5a115ee4c268a185bd350a0
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 18:42:47 2018 +0100

    Install ssh-connection packet handlers synchronously.

    I had a one-off 'Strange packet received' error yesterday for an
    SSH_MSG_GLOBAL_REQUEST at connection startup. I wasn't able to
    reproduce, but examining the packet logs from the successful retry
    suggested that the global request in question was an OpenSSH 'here are
    my hostkeys' message.

    My belief is that in the failing connection that request packet must
    have arrived exceptionally promptly, and been added to pq_full before
    the preceding SSH_MSG_USERAUTH_SUCCESS had been processed. So the code
    that loops along pq_full feeding everything to the dispatch table
    would have moved the USERAUTH_SUCCESS on to pq_ssh2_userauth and
    scheduled a callback to handle it, and then moved on to the
    GLOBAL_REQUEST which would have gone straight to the dispatch table
    handler for 'help, we weren't expecting this message'. The userauth
    callback would later on have installed a more sensible dispatch table
    handler for global requests, but by then, it was too late.

    Solution: make a special case during pq_full processing, so that when
    we see USERAUTH_SUCCESS we _immediately_ - before continuing to
    traverse pq_full - install the initial dispatch table entries for the
    ssh-connection protocol. That way, even if connection messages are
    already in the queue, we won't get confused by them.

 ssh.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 55 insertions(+), 21 deletions(-)