simon-git: putty (master): Simon Tatham

[Commits to Tartarus CVS repository.]

TL;DR:
  10a48c3 Allocate the SSH specials list dynamically.
  75fdfed Add TS_LOCALSTART for session-specific 'Telnet' specials.
  e786452 Add manual cross-certification of new host keys.

Repository:     git://git.tartarus.org/simon/putty.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2016-03-21 07:40:33

commit 10a48c35917011b465b0cdce4521fb91839ee408
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=10a48c35917011b465b0cdce4521fb91839ee408;hp=6ef6cb1573a9a587e4912f735ad837f149f50a5a
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 21 06:50:50 2016 +0000

    Allocate the SSH specials list dynamically.
    
    The last list we returned is now stored in the main Ssh structure
    rather than being a static array in ssh_get_specials.
    
    The main point of this is that I want to start adding more dynamic
    things to it, for which I can't predict the array's max length in
    advance.
    
    But also this fixes a conceptual wrongness, in that if a process had
    more than one Ssh instance in it then their specials arrays would have
    taken turns occupying the old static array, and although the current
    single-threaded client code in the GUI front ends wouldn't have minded
    (it would have read out the contents just once immediately after
    get_specials returned), it still feels as if it was a bug waiting to
    happen.

 ssh.c |   44 ++++++++++++++++++++++++++++++--------------
 1 file changed, 30 insertions(+), 14 deletions(-)

commit 75fdfed80be41ca471c5a34184eeaf5b68bf42c0
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=75fdfed80be41ca471c5a34184eeaf5b68bf42c0;hp=10a48c35917011b465b0cdce4521fb91839ee408
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 21 06:54:26 2016 +0000

    Add TS_LOCALSTART for session-specific 'Telnet' specials.
    
    Now I can invent codes that vary per session.

 putty.h |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

commit e786452cb2dbd190e3b72e68b08a261454151cbe
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=e786452cb2dbd190e3b72e68b08a261454151cbe;hp=75fdfed80be41ca471c5a34184eeaf5b68bf42c0
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 21 07:25:31 2016 +0000

    Add manual cross-certification of new host keys.
    
    If a server offers host key algorithms that we don't have a stored key
    for, they will now appear in a submenu of the Special Commands menu.
    Selecting one will force a repeat key exchange with that key, and if
    it succeeds, will add the new host key to the cache. The idea is that
    the new key sent by the server is protected by the crypto established
    in the previous key exchange, so this is just as safe as typing some
    command like 'ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub' at the
    server prompt and transcribing the results manually.
    
    This allows switching over to newer host key algorithms if the client
    has begun to support them (e.g. people using PuTTY's new ECC
    functionality for the first time), or if the server has acquired a new
    key (e.g. due to a server OS upgrade).
    
    At the moment, it's only available manually, for a single host key
    type at a time. Automating it is potentially controversial for
    security policy reasons (what if someone doesn't agree this is what
    they want in their host key cache, or doesn't want to switch over to
    using whichever of the keys PuTTY would now put top of the list?), for
    code plumbing reasons (chaining several of these rekeys might be more
    annoying than doing one at a time) and for CPU usage reasons (rekeys
    are expensive), but even so, it might turn out to be a good idea in
    future.

 ssh.c |   78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)