simon-git: putty (master): Simon Tatham

Sat Jan 25 18:13:05 GMT 2020

TL;DR:
  98538caa winpgnt: handle WM_COPYDATA requests in a subthread.
  49cd1f71 pageant.c: minor cleanup of struct typedefs.
  de38a4d8 Pageant: new asynchronous internal APIs.
  7bcbc798 Pageant: move signing requests out into a coroutine.

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:           2020-01-25 18:13:05

commit 98538caa39d20f3efe8de307fa5169e9fb0787d2
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=98538caa39d20f3efe8de307fa5169e9fb0787d2;hp=7590d0625ba6e994a00191aa708d3aadee70c407
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Jan 25 17:24:17 2020 +0000

    winpgnt: handle WM_COPYDATA requests in a subthread.

    This is preparation to allow Pageant to be able to return to its GUI
    main loop in the middle of handling a request (e.g. present a dialog
    box to the user related to that particular request, and wait for the
    user's response). In order to do that, we need the main thread's
    Windows message loop to never be blocked by a WM_COPYDATA agent
    request.

    So I've split Pageant's previous hidden window into two hidden
    windows, each with a subset of the original roles, and created in
    different threads so that they get independent message loops. The one
    in the main thread receives messages relating to Pageant's system tray
    icon; the one in the subthread has the identity known to (old) Pageant
    clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is
    handled by passing the request back to the main thread via an event
    object integrated into the Pageant main loop, and then waiting for a
    second event object that the main thread will signal when the answer
    comes back, and not returning from the WndProc handler until the
    response arrives.

    Hence, if an agent request received via WM_COPYDATA requires GUI
    activity, then the main thread's GUI message loop will be able to do
    that in parallel with all Pageant's other activity, including other
    GUI activity (like the key list dialog box) and including responding
    to other requests via named pipe.

    I can't stop WM_COPYDATA requests from blocking _each other_, but this
    allows them not to block anything else. And named-pipe requests block
    nothing at all, so as clients switch over to the new IPC, even that
    blockage will become less and less common.

 windows/winpgnt.c | 161 +++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 106 insertions(+), 55 deletions(-)

commit 49cd1f7116d5991ed2cf1bec58b27e5a722c0585
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=49cd1f7116d5991ed2cf1bec58b27e5a722c0585;hp=98538caa39d20f3efe8de307fa5169e9fb0787d2
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Jan 25 17:24:17 2020 +0000

    pageant.c: minor cleanup of struct typedefs.

    These names are unwieldy enough - and there are about to be several
    more of them - that I want to keep things organised.

 pageant.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

commit de38a4d82697bf5935d30a5b72f2460c4a9bb37d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=de38a4d82697bf5935d30a5b72f2460c4a9bb37d;hp=49cd1f7116d5991ed2cf1bec58b27e5a722c0585
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Jan 25 17:24:28 2020 +0000

    Pageant: new asynchronous internal APIs.

    This is a pure refactoring: no functional change expected.

    This commit introduces two new small vtable-style APIs. One is
    PageantClient, which identifies a particular client of the Pageant
    'core' (meaning the code that handles each individual request). This
    changes pageant_handle_msg into an asynchronous operation: you pass in
    an agent request message and an identifier, and at some later point,
    the got_response method in your PageantClient will be called with the
    answer (and the same identifier, to allow you to match requests to
    responses). The trait vtable also contains a logging system.

    The main importance of PageantClient, and the reason why it has to
    exist instead of just passing pageant_handle_msg a bare callback
    function pointer and context parameter, is that it provides robustness
    if a client stops existing while a request is still pending. You call
    pageant_unregister_client, and any unfinished requests associated with
    that client in the Pageant core will be cleaned up, so that you're
    guaranteed that after the unregister operation, no stray callbacks
    will happen with a stale pointer to that client.

    The WM_COPYDATA interface of Windows Pageant is a direct client of
    this API. The other client is PageantListener, the system that lives
    in pageant.c and handles stream-based agent connections for both Unix
    Pageant and the new Windows named-pipe IPC. More specifically, each
    individual connection to the listening socket is a separate
    PageantClient, which means that if a socket is closed abruptly or
    suffers an OS error, that client can be unregistered and any pending
    requests cancelled without disrupting other connections.

    Users of PageantListener have a second client vtable they can use,
    called PageantListenerClient. That contains _only_ logging facilities,
    and at the moment, only Unix Pageant bothers to use it (and even that
    only in debugging mode).

    Finally, internally to the Pageant core, there's a new trait called
    PageantAsyncOp which describes an agent request in the process of
    being handled. But at the moment, it has only one trivial
    implementation, which is handed the full response message already
    constructed, and on the next toplevel callback, passes it back to the
    PageantClient.

 pageant.c         | 513 +++++++++++++++++++++++++++++++++++-------------------
 pageant.h         | 118 +++++++++++--
 sshcr.h           |   2 +
 unix/uxpgnt.c     |  22 ++-
 windows/winpgnt.c |  44 +++--
 5 files changed, 486 insertions(+), 213 deletions(-)

commit 7bcbc79818a8db820d90ca5b2c040618030cc7dd
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7bcbc79818a8db820d90ca5b2c040618030cc7dd;hp=de38a4d82697bf5935d30a5b72f2460c4a9bb37d
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Jan 25 17:25:28 2020 +0000

    Pageant: move signing requests out into a coroutine.

    The previous commit introduced the PageantAsyncOp trait, with only one
    trivial implementation. This one introduces a second implementation
    used for SSH2_AGENTC_SIGN_REQUEST only, which waits to actually
    construct the signature until after a callback has happened. This will
    allow the signing process to be suspended in order to request a dialog
    box and wait for a user response to decide _how_ to reply.

    Suspended signing operations relating to a particular key are held in
    a linked list dangling from the corresponding PageantKey structure.
    This will allow them all to be found easily if that key should be
    deleted from the agent: in that situation pending signatures from the
    key will all return SSH_AGENT_FAILURE.

    Still no functional change, however: the new coroutine doesn't
    actually wait for anything, it just contains a comment noting that it
    could if it wanted to.

 pageant.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 89 insertions(+), 9 deletions(-)