simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  1d162fa7 Stop sending outgoing-only EOF on SSH sockets.
  db188040 Fix failure to close the outgoing socket.
  5d6d052d Flush log file after asynchronous askappend.

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-10-01 21:07:29

commit 1d162fa767151050db5ea5b84f72b9742c2f7c7d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1d162fa767151050db5ea5b84f72b9742c2f7c7d;hp=fb07fccf2dbd28ea7e3e1771d25e0378b2a28e56
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Oct 1 20:25:15 2018 +0100

    Stop sending outgoing-only EOF on SSH sockets.
    
    When PuTTY wants to cleanly close an SSH connection, my policy has
    been to use shutdown(SHUT_WR) (or rather, sk_write_eof, which ends up
    translating into that) to close just the outgoing side of the TCP
    connection, and then wait for the server to acknowledge that by
    closing its own end.
    
    Mainly the purpose of doing this rather than just immediately closing
    the whole socket was that I wanted to make sure any remaining outgoing
    packets of ours got sent before the connection was wound up. In
    particular, when we send SSH_MSG_DISCONNECT immediately before the
    close, we do want that to get through.
    
    But I now think this was a mistake, because it puts us at the mercy of
    the server remembering to respond by closing the other direction of
    the connection. It might absent-mindedly just continue to sit there
    holding the connection open, which would be silly, but if it did
    happen, we wouldn't want to sit around waiting in order to close the
    client application - we'd rather abandon a socket in that state and
    leave it to the OS's network layer to tell the server how silly it was
    being.
    
    So now I'm using an in-between strategy: I still wait for outgoing
    data to be sent before closing the socket (so the DISCONNECT should
    still go out), but once it's gone, I _do_ just close the whole thing
    instead of just sending outgoing EOF.

 ssh.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

commit db188040ea8c1a8e3f6ae581c1806fbc77f08335
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=db188040ea8c1a8e3f6ae581c1806fbc77f08335;hp=1d162fa767151050db5ea5b84f72b9742c2f7c7d
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Oct 1 21:01:59 2018 +0100

    Fix failure to close the outgoing socket.
    
    A second bug in the area of clean SSH-connection closure: I was
    setting the pending_close flag (formerly send_outgoing_eof) and
    expecting that once the outgoing backlog was cleared it would cause a
    socket closure. But of course the function that does that -
    ssh_bpp_output_raw_data_callback() - will only get called if there
    _is_ any outgoing backlog to be cleared! So if there was already no
    backlog, I would set the pending_close flag and nothing would ever
    check it again.
    
    Fixed by manually re-queuing the callback that will check the backlog
    and the pending_close flag.

 ssh.c | 1 +
 1 file changed, 1 insertion(+)

commit 5d6d052d8b28bdaf4fc0cba29234909727f46b6c
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5d6d052d8b28bdaf4fc0cba29234909727f46b6c;hp=db188040ea8c1a8e3f6ae581c1806fbc77f08335
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Oct 1 21:03:34 2018 +0100

    Flush log file after asynchronous askappend.
    
    When I made the 'overwrite or append log file?' dialog box into a
    non-modal one, it exposed a bug in logging.c's handling of an
    asynchronous response to askappend(): we queued all the pending log
    data and wrote it out to the log file, but forgot the final fflush
    that would have made sure it all actually _went_ to the log file. So
    one stdio buffer's worth could still be held in the C library, to be
    released the next time log data shows up.
    
    Added the missing logflush().

 logging.c | 1 +
 1 file changed, 1 insertion(+)