simon-git: putty (master): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Sun Sep 29 16:16:20 BST 2019


TL;DR:
  2c279283 Don't call term_bracketed_paste_stop before pasted data.
  15653f67 winnet: use SO_EXCLUSIVEADDRUSE for listening sockets.
  69201ad8 Fix use-after-free on SSH1_MSG_DISCONNECT.
  745ed3ad Update version number for 0.73 release.

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:           2019-09-29 16:16:20

commit 2c279283cc695ade15bafb418a8207ef0edd89cd
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=2c279283cc695ade15bafb418a8207ef0edd89cd;hp=8b87d80a8483c82f4e1479e45d26e103ab853154
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Aug 3 18:09:05 2019 +0100

    Don't call term_bracketed_paste_stop before pasted data.
    
    The redesign in commit 9fccb065a arranged that all keystroke data goes
    via term_keyinput_internal, which calls term_bracketed_paste_stop just
    in case the keystroke had interrupted an in-progress paste.
    
    But, embarrassingly, I forgot that _pasted_ data also goes via
    term_keyinput_internal, and bracketed paste mode certainly should not
    be terminated before _that_ is sent! I should have conditionalised the
    call to term_bracketed_paste_stop on the 'interactive' flag parameter,
    which is precisely there to tell the difference between pastes and
    true keyboard input.

 terminal.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

commit 15653f67e8559787d021dda415d93696e98d1804
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=15653f67e8559787d021dda415d93696e98d1804;hp=2c279283cc695ade15bafb418a8207ef0edd89cd
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Aug 3 18:22:08 2019 +0100

    winnet: use SO_EXCLUSIVEADDRUSE for listening sockets.
    
    Thanks to Patrick Stekovic for pointing out that, unlike sensible IP
    stacks, Windows requires a non-default socket option to prevent a
    second application from binding to a port you were already listening
    on, causing some of your incoming connections to be diverted.
    
    This replaces the previous setsockopt that enabled SO_REUSEADDR, which
    I put there a long time ago in order to fix an annoying behaviour if
    you used the same listening socket twice in rapid succession (e.g. for
    successive PuTTYs forwarding the same port) and the second one failed
    to bind the listening port because a left-over connection from the
    first one was still in TIME_WAIT and causing the port number to be
    marked as used.
    
    As far as I can see, SO_EXCLUSIVEADDRUSE and SO_REUSEADDR are mutually
    exclusive - if I try to set both, either way round, then setsockopt
    returns failure on the second one - so if I have to set the former
    then I _can't_ set the latter. And fortunately, re-testing on Windows
    10, the TIME_WAIT problem that SO_REUSEADDR was supposed to solve
    doesn't seem to exist any more: I deliberately tried listening on a
    port that had a TIME_WAIT connection sitting on it, and it worked for
    me even without SO_REUSEADDR.
    
    (I can't remember now whether I definitely confirmed the TIME_WAIT
    problem on a previous version of Windows, or whether I just assumed it
    would happen on Windows in the same way as Linux, where I definitely
    do remember observing it.)
    
    While I'm changing that setsockopt call, I've also fixed its 'on'
    parameter so that it's a BOOL rather than an int, in accordance with
    the docs for WinSock setsockopt.

 windows/winnet.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

commit 69201ad8936fe0ff1b8723b7a43accb5e9f1c888
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=69201ad8936fe0ff1b8723b7a43accb5e9f1c888;hp=15653f67e8559787d021dda415d93696e98d1804
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Sep 20 14:08:53 2019 +0100

    Fix use-after-free on SSH1_MSG_DISCONNECT.
    
    Thanks to Ulrich Jannet for pointing this out: in
    ssh2_connection_filter_queue, when we process a disconnect message, we
    carefully avoid dereferencing the input 'ppl' pointer after
    ssh_remote_error returns, because it will have been freed. But
    ssh1_connection_filter_queue didn't have the same safety precaution.

 sshcommon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 745ed3ad3beaf52fc623827e770b3a068b238dd5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=745ed3ad3beaf52fc623827e770b3a068b238dd5;hp=69201ad8936fe0ff1b8723b7a43accb5e9f1c888
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Sep 22 10:12:29 2019 +0100

    Update version number for 0.73 release.

 Buildscr      | 2 +-
 LATEST.VER    | 2 +-
 doc/plink.but | 2 +-
 doc/pscp.but  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)



More information about the tartarus-commits mailing list