simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  dc875ca0 Make rekeys work when KEXINIT filtering is enabled.
  9af70535 Uppity: clear the right KEXINIT packet at kex startup!

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2022-09-10 10:24:29

commit dc875ca0dc07a492a3707e1ac47b95d90e92edd4
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=dc875ca0dc07a492a3707e1ac47b95d90e92edd4;hp=8590b7f2e20d40678901438a2482837dac491851
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Sep 10 10:15:27 2022 +0100

    Make rekeys work when KEXINIT filtering is enabled.
    
    I only realised this bug while writing up the feature for the
    wishlist:
    
    It's one thing _at connection startup_ to delay sending your KEXINIT
    until the server has sent its: the server is very likely to send it
    anyway (unless it's attempting the same workaround against us), so
    probably nothing goes wrong.
    
    But if we want to initiate a rekey, we do that _by_ sending a KEXINIT.
    In that situation we can't just wait until the server sends one,
    because it has no idea it's supposed to be doing so!
    
    Happily, in that situation, we already have a KEXINIT from the server,
    left over from the previous key exchange. So we can filter against
    that, and still have the intended effect of not spending KEXINIT space
    on algorithms the server doesn't know about.

 ssh/transport2.c | 62 ++++++++++++++++++++++++++++++++++++++++----------------
 ssh/transport2.h |  2 +-
 2 files changed, 46 insertions(+), 18 deletions(-)

commit 9af705352d2ca149cc7c2200af82b72b4fdc4d45
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=9af705352d2ca149cc7c2200af82b72b4fdc4d45;hp=dc875ca0dc07a492a3707e1ac47b95d90e92edd4
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Sep 10 10:19:03 2022 +0100

    Uppity: clear the right KEXINIT packet at kex startup!
    
    Just spotted this in eyeball review: we're about to construct our new
    outgoing KEXINIT and write it into the strbuf s->outgoing_kexinit. So
    we should clear that strbuf first. But in fact we were clearing
    s->client_kexinit, which aliases s->outgoing_kexinit in an SSH client,
    but in a server, aliases s->incoming_kexinit.
    
    This was harmless in PuTTY (since the strbuf we cleared was the right
    one anyway). And it was harmless in Uppity's initial kex (since the
    strbuf we _meant_ to clear was empty anyway). But if Uppity had ever
    initiated a rekey, this would have exploded messily.

 ssh/transport2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)