Rewrite authentication flow to handle new keysHEADmaster

Previously, running /auth command would immediately send off request
with the provided username, and all keyring actions will only happen
once the client receives the challenge. This isn't possible now that we
have both software X25519 and hardware P-256 keys because we must signal
which key type we're using in advance.

Rather than deferring everything until the challenge, perform the key
setup immediately. Parse it, load it into the auth state, and send the
full request. When the challenge is received, all that's left is to
unlock the already resolved key. In case user cancels the prompt, open
key selection dialog again.

Make auth state machine stricter, so it's more consistent and easier to
reason about, and only expose small interface. In particular, it
provides key switching without restarting the auth flow. The state
itself is only initialized once at program start, fully static, and
avoids superflous allocations and deletions which could result in
invalid states. Unify auth-related structures under it that were
previously separate, such as saved hostname-username pairs. Send signals
about request and response being ready instead of directly using the
network functions, which makes it especially better fit in context of
two asynchronous dialogs.

To properly encode hardware or software key type in the intitial request
without creating a separate packet, an extension to subprotocol 2 was
introduced in a format-violating manner: an extension bit set means a
hardware key is used, and thus we'll expect an ephemeral P-256 key as
the challenge. The entire credential message format will be completely
rewritten in version 3, this is a prototype implementation.

0 files changed, 0 insertions, 0 deletions