simon-git: putty (main): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Tue Apr 26 11:30:54 BST 2022


TL;DR:
  f9775a7b Make ssh_keyalg's supported_flags a method.
  cf36b921 ssh_keyalg: new method 'alternate_ssh_id'.
  68514ac8 Refactor the key-components mechanism a bit.
  62bc6c54 New key component type KCT_BINARY.
  180d1b78 Extra helper functions for adding key_components.
  c2f1a563 Utility function ssh_key_clone().
  69e8d471 Move our DialogBox wrapper into windows/utils.
  cccdab9b Windows: utility function to centre a window.
  1bd2af1f Windows: refactor config-box creation code.
  043c2484 Improve the base64 utility functions.
  2a26ebd0 Turn the proxy type radio buttons into a dropdown list.
  6f7c52dc Add exec/subsystem versions of SSH proxying.
  34d01e1b Family of key types for OpenSSH certificates.
  9f583c4f Certificate-specific ssh_key method suite.
  4cde00ef OpenSSH key export: strip certificates.
  7cb3142a PuTTYgen: options to add and remove certificates.
  df3a21d9 Support for detached certificates in userauth.
  21d4754b Initial support for host certificates.
  254635a2 Test implementation of a CA in Python.
  36d40feb Add cryptsuite test of certificate handling.

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-04-26 11:30:54

commit f9775a7b676c8878239eafe8c88cc6b9240eda86
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=f9775a7b676c8878239eafe8c88cc6b9240eda86;hp=6143a50ed228fdf5a72c2970629b4ff643d001fc
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Apr 19 17:05:36 2022 +0100

    Make ssh_keyalg's supported_flags a method.
    
    It's a class method rather than an object method, so it doesn't allow
    keys with the same algorithm to make different choices about what
    flags they support. But that's not what I wanted it for: the real
    purpose is to allow one key algorithm to delegate supported_flags to
    another, by having its method implementation call the one from the
    delegate class.
    
    (If only C's compile/link model permitted me to initialise a field of
    one global const struct variable to be a copy of that of another, I
    wouldn't need the runtime overhead of this method! But object file
    formats don't let you even specify that.)
    
    Most key algorithms support no flags at all, so they all want to use
    the same implementation of this method. So I've started a file of
    stubs utils/nullkey.c to contain the common stub version.

 crypto/dsa.c         |  1 +
 crypto/ecc-ssh.c     |  5 +++++
 crypto/rsa.c         | 11 ++++++++---
 pageant.c            |  2 +-
 ssh.h                |  9 ++++++++-
 utils/CMakeLists.txt |  1 +
 utils/nullkey.c      |  6 ++++++
 7 files changed, 30 insertions(+), 5 deletions(-)

commit cf36b9215f972ef883ed6d10062e1cad0255e470
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=cf36b9215f972ef883ed6d10062e1cad0255e470;hp=f9775a7b676c8878239eafe8c88cc6b9240eda86
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Apr 19 17:27:54 2022 +0100

    ssh_keyalg: new method 'alternate_ssh_id'.
    
    Previously, the fact that "ssh-rsa" sometimes comes with two subtypes
    "rsa-sha2-256" and "rsa-sha2-512" was known to three different parts
    of the code - two in userauth and one in transport. Now the knowledge
    of what those ids are, which one goes with which signing flags, and
    which key types have subtypes at all, is centralised into a method of
    the key algorithm, and all those locations just query it.
    
    This will enable the introduction of further key algorithms that have
    a parallel upgrade system.

 crypto/dsa.c           |  1 +
 crypto/ecc-ssh.c       |  5 +++++
 crypto/rsa.c           | 12 +++++++++++
 ssh.h                  |  5 +++++
 ssh/transport2.c       | 22 +++++++++++--------
 ssh/userauth2-client.c | 58 +++++++++++++++++++++++++++++---------------------
 utils/nullkey.c        |  7 ++++++
 7 files changed, 77 insertions(+), 33 deletions(-)

commit 68514ac8a1fd6b588dedd6c88cd3003b88947783
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=68514ac8a1fd6b588dedd6c88cd3003b88947783;hp=cf36b9215f972ef883ed6d10062e1cad0255e470
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Apr 18 10:10:57 2022 +0100

    Refactor the key-components mechanism a bit.
    
    Having recently pulled it out into its own file, I think it could also
    do with a bit of tidying. In this rework:
    
     - the substructure for a single component now has a globally visible
       struct tag, so you can make a variable pointing at it, saving
       verbiage in every piece of code looping over a key_components
    
     - the 'is_mp_int' flag has been replaced with a type enum, so that
       more types can be added without further upheaval
    
     - the printing loop in cmdgen.c for puttygen --dump has factored out
       the initial 'name=' prefix on each line so that it isn't repeated
       per component type
    
     - the storage format for text components is now a strbuf rather than
       a plain char *, which I think is generally more useful.

 cmdgen.c               | 21 ++++++++++++++-------
 ssh.h                  | 20 ++++++++++++--------
 test/testcrypt-func.h  |  2 +-
 test/testcrypt.c       | 12 +++++++-----
 utils/key_components.c | 23 ++++++++++++++---------
 5 files changed, 48 insertions(+), 30 deletions(-)

commit 62bc6c5448514fc77386526b773fc4508945d9cd
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=62bc6c5448514fc77386526b773fc4508945d9cd;hp=68514ac8a1fd6b588dedd6c88cd3003b88947783
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Apr 18 10:06:31 2022 +0100

    New key component type KCT_BINARY.
    
    This stores its data in the same format as the existing KCT_TEXT, but
    it displays differently in puttygen --dump, expecting that the data
    will be full of horrible control characters, invalid UTF-8, etc.
    
    The displayed data is of the form b64("..."), so you get a hint about
    what the encoding is, and can still paste into Python by defining the
    identifier 'b64' to be base64.b64decode or equivalent.

 cmdgen.c               | 32 ++++++++++++++++++++++++++++++++
 ssh.h                  |  6 ++++--
 test/testcrypt.c       |  3 ++-
 utils/key_components.c | 21 +++++++++++++++++----
 4 files changed, 55 insertions(+), 7 deletions(-)

commit 180d1b78de90f2e3fd93939664322185ebbabc00
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=180d1b78de90f2e3fd93939664322185ebbabc00;hp=62bc6c5448514fc77386526b773fc4508945d9cd
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Apr 18 10:08:10 2022 +0100

    Extra helper functions for adding key_components.
    
    In this commit, I provide further functions which generate the
    existing set of data types:
    
     - key_components_add_text_pl() adds a text component, but takes a
       ptrlen rather than a const char *, in case that was what you
       happened to have already.
    
     - key_components_add_uint() ends up adding an mp_int to the
       structure, but takes it as input in the form of an ordinary C
       integer, for the convenience of call sites which will want to do
       that a lot and don't enjoy repeating the mp_int construction
       boilerplate
    
     - key_components_add_copy() takes a pointer to one of the
       key_component sub-structs in an existing key_components, and copies
       it into the output key_components under a new name, handling
       whatever type it turns out to have.

 ssh.h                  |  6 ++++++
 utils/key_components.c | 29 +++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

commit c2f1a563a50bd611aaf330142e828dfb1b43f18e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c2f1a563a50bd611aaf330142e828dfb1b43f18e;hp=180d1b78de90f2e3fd93939664322185ebbabc00
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Apr 20 13:51:28 2022 +0100

    Utility function ssh_key_clone().
    
    This makes a second independent copy of an existing ssh_key, for
    situations where one piece of code is going to want to keep it after
    its current owner frees it.
    
    In order to have it work on an arbitrary ssh_key, whether public-only
    or a full public+private key pair, I've had to add an ssh_key query
    method to ask whether a private key is known. I'm surprised I haven't
    found a need for that before! But I suppose in most situations in an
    SSH client you statically know which kind of key you're dealing with.

 crypto/dsa.c          |  7 +++++++
 crypto/ecc-ssh.c      | 17 +++++++++++++++++
 crypto/rsa.c          |  7 +++++++
 ssh.h                 |  6 ++++++
 utils/CMakeLists.txt  |  1 +
 utils/ssh_key_clone.c | 32 ++++++++++++++++++++++++++++++++
 6 files changed, 70 insertions(+)

commit 69e8d471d1343f3532bef941aa6f25cd3679cdeb
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=69e8d471d1343f3532bef941aa6f25cd3679cdeb;hp=c2f1a563a50bd611aaf330142e828dfb1b43f18e
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Apr 25 14:08:00 2022 +0100

    Move our DialogBox wrapper into windows/utils.
    
    It's self-contained enough not to really need to live in dialog.c as a
    set of static functions. Also, moving it means we can isolate the
    implementation details - which also makes it easy to change them.
    
    One such change is that I've added the ability to bake a context
    pointer into the dialog - unused so far, but it will be shortly.
    
    (Also, while I'm here, renamed the functions so they sound more as if
    they're adding features than working around bugs - not to mention not
    imputing mental illness to the usual versions.)

 windows/CMakeLists.txt         |   1 +
 windows/dialog.c               |  72 ++++----------------------
 windows/platform.h             |   8 +--
 windows/utils/shinydialogbox.c | 111 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 127 insertions(+), 65 deletions(-)

commit cccdab9ba6dbe20dd4a991a9ac787d8901132dfe
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=cccdab9ba6dbe20dd4a991a9ac787d8901132dfe;hp=69e8d471d1343f3532bef941aa6f25cd3679cdeb
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Apr 24 13:34:15 2022 +0100

    Windows: utility function to centre a window.
    
    This was called from config box setup, and is obviously the kind of
    thing that ought to be a reusable utility function.

 windows/CMakeLists.txt        |  1 +
 windows/dialog.c              | 17 +++--------------
 windows/platform.h            |  2 ++
 windows/utils/centre_window.c | 20 ++++++++++++++++++++
 4 files changed, 26 insertions(+), 14 deletions(-)

commit 1bd2af1f875b8c7927906eadaf578013df8d999f
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1bd2af1f875b8c7927906eadaf578013df8d999f;hp=cccdab9ba6dbe20dd4a991a9ac787d8901132dfe
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Apr 23 15:01:29 2022 +0100

    Windows: refactor config-box creation code.
    
    I'm about to want to create a second entirely different dialog box
    whose contents are described using the same dialog.h API as the main
    config box. So I'm starting by moving as much handler code as possible
    out of GenericMainDlgProc and its callers, and into a set of reusable
    subroutines.
    
    In particular, this gets rid of the disgusting static variables that
    stored all the config-box state. Now they're stored in a more sensible
    struct, which lives in the new context-pointer field provided by the
    reworked ShinyDialogBox.

 windows/dialog.c | 408 ++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 235 insertions(+), 173 deletions(-)

commit 043c24844a45a209697383e6847f35872232a287
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=043c24844a45a209697383e6847f35872232a287;hp=1bd2af1f875b8c7927906eadaf578013df8d999f
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Apr 22 11:22:56 2022 +0100

    Improve the base64 utility functions.
    
    The low-level functions to handle a single atom of base64 at a time
    have been in 'utils' / misc.h for ages, but the higher-level family of
    base64_encode functions that handle a whole data block were hidden
    away in sshpubk.c, and there was no higher-level decode function at
    all.
    
    Now moved both into 'utils' modules and declared them in misc.h rather
    than ssh.h. Also, improved the APIs: they all take ptrlen in place of
    separate data and length arguments, their naming is more consistent
    and more explicit (the previous base64_encode which didn't name its
    destination is now base64_encode_fp), and the encode functions now
    accept cpl == 0 as a special case meaning that the output base64 data
    is wanted in the form of an unbroken single-line string with no
    trailing \n.

 import.c              |  6 +++---
 misc.h                |  6 ++++++
 ssh.h                 |  4 ----
 sshpubk.c             | 37 +++----------------------------------
 utils/CMakeLists.txt  |  2 ++
 utils/base64_decode.c | 37 +++++++++++++++++++++++++++++++++++++
 utils/base64_encode.c | 40 ++++++++++++++++++++++++++++++++++++++++
 7 files changed, 91 insertions(+), 41 deletions(-)

commit 2a26ebd0d58a4adb6d5f2c3fde0db01525837d74
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=2a26ebd0d58a4adb6d5f2c3fde0db01525837d74;hp=043c24844a45a209697383e6847f35872232a287
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Apr 22 14:55:44 2022 +0100

    Turn the proxy type radio buttons into a dropdown list.
    
    This makes room to add more entries without the Proxy panel
    overflowing. It also means we can put in a bit more explanation in
    some of the more cryptic one-word names!

 config.c           | 76 +++++++++++++++++++++++++++++++++++++++---------------
 putty.h            |  7 +++++
 unix/config-unix.c | 29 +++------------------
 windows/config.c   | 29 +++------------------
 4 files changed, 68 insertions(+), 73 deletions(-)

commit 6f7c52dccee36f6593a3fa4498ce1cc5d9952c66
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=6f7c52dccee36f6593a3fa4498ce1cc5d9952c66;hp=2a26ebd0d58a4adb6d5f2c3fde0db01525837d74
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Apr 22 14:12:15 2022 +0100

    Add exec/subsystem versions of SSH proxying.
    
    This is a simple tweak to the existing in-process SSH jump host
    support, where instead of opening a direct-tcpip channel to the
    destination host, we open a session channel and run a process in it to
    make the connection to the destination.
    
    So, where the existing jump host support replaced a local proxy
    command along the lines of "plink %proxyhost -nc %host %port", this
    one replaces "plink %proxyhost run-some-command".
    
    Also added a corresponding option to use a subsystem to make the
    connection. (Someone could configure an SSH server to support specific
    subsystem names for particular destinations, or a general schema of
    subsystem names that include the destination address in some standard
    format.)
    
    To avoid overflowing the already-full Proxy config panel with an extra
    subtype selector, I've put these in as additional top-level proxy
    types, so that instead of just PROXY_SSH we now have three
    PROXY_SSH_foo.

 config.c         |  4 +++-
 proxy/proxy.c    |  4 +++-
 proxy/sshproxy.c | 48 ++++++++++++++++++++++++++++++++++++++++++------
 putty.h          |  3 ++-
 4 files changed, 50 insertions(+), 9 deletions(-)

commit 34d01e1b654d8c42ebd7f8abc05f5c2693f2a6a1
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=34d01e1b654d8c42ebd7f8abc05f5c2693f2a6a1;hp=6f7c52dccee36f6593a3fa4498ce1cc5d9952c66
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Apr 19 14:48:31 2022 +0100

    Family of key types for OpenSSH certificates.
    
    This commit is groundwork for full certificate support, but doesn't
    complete the job by itself. It introduces the new key types, and adds
    a test in cryptsuite ensuring they work as expected, but nothing else.
    
    If you manually construct a PPK file for one of the new key types, so
    that it has a certificate in the public key field, then this commit
    enables PuTTY to present that key to a server for user authentication,
    either directly or via Pageant storing and using it. But I haven't yet
    provided any mechanism for making such a PPK, so by itself, this isn't
    much use.
    
    Also, these new key types are not yet included in the KEXINIT host
    keys list, because if they were, they'd just be treated as normal host
    keys, in that you'd be asked to manually confirm the SSH fingerprint
    of the certificate. I'll enable them for host keys once I add the
    missing pieces.

 crypto/CMakeLists.txt  |   1 +
 crypto/openssh-certs.c | 660 +++++++++++++++++++++++++++++++++++++++++++++++++
 ssh.h                  |  10 +
 sshpubk.c              |   8 +
 test/testcrypt-enum.h  |   6 +
 5 files changed, 685 insertions(+)

commit 9f583c4fa8f632c349e6b335a4ab5cd69b0a76f9
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=9f583c4fa8f632c349e6b335a4ab5cd69b0a76f9;hp=34d01e1b654d8c42ebd7f8abc05f5c2693f2a6a1
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Apr 20 13:06:08 2022 +0100

    Certificate-specific ssh_key method suite.
    
    Certificate keys don't work the same as normal keys, so the rest of
    the code is going to have to pay attention to whether a key is a
    certificate, and if so, treat it differently and do cert-specific
    stuff to it. So here's a collection of methods for that purpose.
    
    With one exception, these methods of ssh_key are not expected to be
    implemented at all in non-certificate key types: they should only ever
    be called once you already know you're dealing with a certificate. So
    most of the new method pointers can be left out of the ssh_keyalg
    initialisers.
    
    The exception is the base_key method, which retrieves the base key of
    a certificate - the underlying one with the certificate stripped off.
    It's convenient for non-certificate keys to implement this too, and
    just return a pointer to themselves. So I've added an implementation
    in nullkey.c doing that. (The returned pointer doesn't transfer
    ownership; you have to use the new ssh_key_clone() if you want to keep
    the base key after freeing the certificate key.)
    
    The methods _only_ implemented in certificates:
    
    Query methods to return the public key of the CA (for looking up in a
    list of trusted ones), and to return the key id string (which exists
    to be written into log files).
    
    Obviously, we need a check_cert() method which will verify the CA's
    actual signature, not to mention checking all the other details like
    the principal and the validity period.
    
    And there's another fiddly method for dealing with the RSA upgrade
    system, called 'related_alg'. This is quite like alternate_ssh_id, in
    that its job is to upgrade one key algorithm to a related one with
    more modern RSA signing flags (or any other similar thing that might
    later reuse the same mechanism). But where alternate_ssh_id took the
    actual signing flags as an argument, this takes a pointer to the
    upgraded base algorithm. So it answers the question "What is to this
    key algorithm as you are to its base?" - if you call it on
    opensshcert_ssh_rsa and give it ssh_rsa_sha512, it'll give you back
    opensshcert_ssh_rsa_sha512.
    
    (It's awkward to have to have another of these fiddly methods, and in
    the longer term I'd like to try to clean up their proliferation a bit.
    But I even more dislike the alternative of just going through
    all_keyalgs looking for a cert algorithm with, say, ssh_rsa_sha512 as
    the base: that approach would work fine now but it would be a lurking
    time bomb for when all the -cert-v02@ methods appear one day. This
    way, each certificate type can upgrade itself to the appropriately
    related version. And at least related_alg is only needed if you _are_
    a certificate key type - it's not adding yet another piece of
    null-method boilerplate to the rest.)

 crypto/dsa.c           |   1 +
 crypto/ecc-ssh.c       |   5 ++
 crypto/openssh-certs.c | 221 ++++++++++++++++++++++++++++++++++++++++++++++++-
 crypto/rsa.c           |   1 +
 ssh.h                  |  23 +++++
 test/testcrypt-func.h  |   8 ++
 test/testcrypt.c       |  33 ++++++++
 utils/nullkey.c        |   6 ++
 8 files changed, 294 insertions(+), 4 deletions(-)

commit 4cde00efc07297976a0fa391f51a07e34f355067
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=4cde00efc07297976a0fa391f51a07e34f355067;hp=9f583c4fa8f632c349e6b335a4ab5cd69b0a76f9
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Apr 22 16:53:30 2022 +0100

    OpenSSH key export: strip certificates.
    
    As far as I can tell, OpenSSH never stores private key files
    containing a certified key. I plan to provide that as an option in
    PuTTY (though not the only option); so if we get a certified key as
    input to the export functions, we need to strip it back to the base
    key to save it into either OpenSSH format.

 import.c | 51 ++++++++++++++++++++++++++++++---------------------
 1 file changed, 30 insertions(+), 21 deletions(-)

commit 7cb3142a57ed01bf2a26975b5727a9a02a4e4e7a
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7cb3142a57ed01bf2a26975b5727a9a02a4e4e7a;hp=4cde00efc07297976a0fa391f51a07e34f355067
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Apr 19 17:59:46 2022 +0100

    PuTTYgen: options to add and remove certificates.
    
    This allows you to actually use an OpenSSH user certificate for
    authentication, by combining the PPK you already had with the
    certificate from the CA to produce a new PPK whose public half
    contains the certificate.
    
    I don't intend that this should be the only way to do it. It's
    cumbersome to have to use the key passphrase in order to re-encrypt
    the modified PPK. But the flip side is that once you've done it you
    have everything you need in one convenient file, and also, the
    certificate itself is covered by the PPK's tamperproofing (in case you
    can think of any attacks in which the admin of your file server swaps
    out just the certificate for a different one on the same key). So this
    is *a* useful way to do it, even if not the only useful way.
    
    The new options to add and remove certificates are supported by both
    Windows GUI PuTTYgen and cmdgen. cmdgen can also operate on pure
    public keys, so you can say 'puttygen --remove-certificate
    foo-cert.pub' and get back the underlying foo.pub; Windows PuTTYgen
    doesn't support that mode, but only because it doesn't in general have
    any support for the loaded key not being a full public+private pair.

 cmdgen.c           | 157 +++++++++++++++++++++++++++++++++++++++++-
 windows/puttygen.c | 195 +++++++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 337 insertions(+), 15 deletions(-)

commit df3a21d97b5f1d022d561cd58da843bf6a87340b
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=df3a21d97b5f1d022d561cd58da843bf6a87340b;hp=7cb3142a57ed01bf2a26975b5727a9a02a4e4e7a
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Apr 21 10:55:44 2022 +0100

    Support for detached certificates in userauth.
    
    This is triggered by a new config option, or alternatively a -cert
    command-line option. You provide a certificate file (i.e. a public key
    containing one of the cert key formats), and then, whenever you
    authenticate with a private key that matches the public key inside
    that certificate, the certificate will be sent to the server in place
    of whatever public key it would have used before.
    
    I expect this to be more convenient for some users than the approach
    of baking the certificate into a modified version of the PPK file -
    especially users who want to use different certificates on the same
    key, either in sequence (if a CA continually reissues certificates
    with short lifetimes) or in parallel (if different hosts trust
    different CAs).
    
    In particular, this substitution is applied consistently, even when
    doing authentication via an agent. So if your bare private key is held
    in Pageant, you can _still_ specify a detached certificate, and PuTTY
    will spot that the key it's picked from Pageant matches that
    certificate, and do the same substitution.
    
    The detached certificate also overrides an existing certificate, if
    there was one on the public key already.

 cmdline.c              |  10 ++
 config.c               |   4 +
 putty.h                |   1 +
 settings.c             |   2 +
 ssh/ppl.h              |   6 +-
 ssh/ssh.c              |   1 +
 ssh/userauth2-client.c | 256 ++++++++++++++++++++++++++++++++++++++++++++++---
 7 files changed, 264 insertions(+), 16 deletions(-)

commit 21d4754b6a0c98c6d75f5a374ff71f108263f02f
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=21d4754b6a0c98c6d75f5a374ff71f108263f02f;hp=df3a21d97b5f1d022d561cd58da843bf6a87340b
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Apr 22 12:07:24 2022 +0100

    Initial support for host certificates.
    
    Now we offer the OpenSSH certificate key types in our KEXINIT host key
    algorithm list, so that if the server has a certificate, they can send
    it to us.
    
    There's a new storage.h abstraction for representing a list of trusted
    host CAs, and which ones are trusted to certify hosts for what
    domains. This is stored outside the normal saved session data, because
    the whole point of host certificates is to avoid per-host faffing.
    
    Configuring this set of trusted CAs is done via a new GUI dialog box,
    separate from the main PuTTY config box (because it modifies a single
    set of settings across all saved sessions), which you can launch by
    clicking a button in the 'Host keys' pane. The GUI is pretty crude for
    the moment, and very much at a 'just about usable' stage right now. It
    will want some polishing.
    
    If we have no CA configured that matches the hostname, we don't offer
    to receive certified host keys in the first place. So for existing
    users who haven't set any of this up yet, nothing will immediately
    change.
    
    Currently, if we do offer to receive certified host keys and the
    server presents one signed by a CA we don't trust, PuTTY will bomb out
    unconditionally with an error, instead of offering a confirmation box.
    That's an unfinished part which I plan to fix before this goes into a
    release.

 config.c                 | 379 +++++++++++++++++++++++++++++++++++++++++++++++
 defs.h                   |   2 +
 putty.h                  |   5 +
 ssh/kex2-client.c        | 101 ++++++++++---
 ssh/transport2.c         | 104 +++++++++++--
 ssh/transport2.h         |  31 ++--
 storage.h                |  23 +++
 unix/dialog.c            |  81 ++++++++++
 unix/storage.c           | 145 +++++++++++++++++-
 utils/CMakeLists.txt     |   1 +
 utils/host_ca_free.c     |  14 ++
 windows/dialog.c         |  38 +++++
 windows/putty-common.rc2 |   9 ++
 windows/putty-rc.h       |   1 +
 windows/storage.c        | 123 +++++++++++++++
 15 files changed, 1014 insertions(+), 43 deletions(-)

commit 254635a2a1a5123e9053641f3418a5c46277d5a2
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=254635a2a1a5123e9053641f3418a5c46277d5a2;hp=21d4754b6a0c98c6d75f5a374ff71f108263f02f
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Apr 25 11:03:24 2022 +0100

    Test implementation of a CA in Python.
    
    This is mostly intended to be invoked from cryptsuite, so that I can
    make test certificates with various features to check the validation
    function. But it also has a command-line interface, which currently
    contains just enough features that I was able to generate a
    certificate and actually make sure OpenSSH accepted it (proving that I
    got the format right in this script).
    
    You _could_ expand this script into a full production CA, with a
    couple more command-line options, if you didn't mind the slightly
    awkward requirement that in command-line mode it insists on doing its
    signing via an SSH agent. But for the moment it's only intended for
    test purposes.

 test/ca.py  | 198 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 test/ssh.py |   7 +++
 2 files changed, 205 insertions(+)

commit 36d40febeddae0af8d38ed8e9f9b60eee69c50e4
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=36d40febeddae0af8d38ed8e9f9b60eee69c50e4;hp=254635a2a1a5123e9053641f3418a5c46277d5a2
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Apr 25 13:27:53 2022 +0100

    Add cryptsuite test of certificate handling.
    
    This uses the test-CA code to construct a series of certificates with
    various properties so as to check all the error cases of certificate
    validation. It also tests the various different key types, and all the
    RSA signature flags on both the certified key and the certifying one.

 test/cryptsuite.py | 218 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 218 insertions(+)



More information about the tartarus-commits mailing list