Recent commits to derivepassphrase.git (5959cb77d6074f26c59cfe5342592aef52c94aee)

Document that `is_suitable_ssh_key` now takes an optional agent client in the changelog

2024-11-27T13:29:15+01:00

</pre>

Add an ecdsa-sha2-nistp521 SSH test key

2024-11-27T00:09:55+01:00

This case was apparently forgotten when adding the 256- and 384-bit
keys.
</pre>

Publish polished `is_suitable_ssh_key` and `has_deterministic_dsa_signatures` interfaces

2024-11-26T23:28:43+01:00

The `has_deterministic_signatures` function internally only ever checked
whether DSA signatures were known deterministic, because currently,
signature schemes are either deterministic by design or they are
DSA-like and can be derandomized via RFC 6979 or a similar procedure.
There's no guarantee this dichotomy will stay this way in the future.
Thus it is better to rename the function to match what it actually
tests: Does this agent use deterministic DSA and ECDSA signatures?  We
do just that.

In a similar vein, the `Vault._is_suitable_ssh_key` only really checks
if the key type is known deterministic, not whether the key is suitable;
the latter depends on the SSH agent, and requires a call to the old
`has_deterministic_signatures` function.  We could of course analogously
rename `_is_suitable_ssh_key` into `is_known_deterministic_key_type` or
similar, but this feels too much like exposing implementation details to
the API user.  It seems better to expose a `Vault.is_suitable_ssh_key`
method that actually does what it advertises: check whether a key type
is known deterministic under a given SSH agent, or under all SSH agents
in general.  So we do just that.

Finally, we clean up some inconsistencies in the `query_extensions`
docstring, and some missing SSH agent clients not passed on to the calls
to the `Vault.phrase_from_key` function in the tests.
</pre>

Let the `running_ssh_agent` test fixture report the agent type

2024-11-26T14:26:21+01:00

In the current test scenario, where multiple SSH agents are spawned if
possible, it is highly unhelpful to know *that* a running SSH agent
failed, but not *which* agent did.  For debugging purposes, it is better
if the `running_ssh_agent` test fixture reports not only the agent's
socket, but also its type.

It is sufficient to have the type passed as a fixture output/test
function input, because `pytest` will then pretty-print it when a test
function fails.
</pre>

Decouple deterministic signatures from general SSH agent detection

2024-11-26T14:12:53+01:00

Instead of tying deterministic signatures directly to the detection of
Pageant specifically, add a general mechanism for attempting to infer
the connected SSH agent from its reported list of extensions.  This
moves the question of *how* we detect certain SSH agents out of the
deterministic signature checking function.

Alas, OpenSSH does not support the extension query message we issue,
despite them supporting the extension system in general *and* stewarding
the SSH agent protocol specification which defines this message
normatively.  So our implementation must tolerate a moderate level of
spec violation.
</pre>

Fix test suite to actually test deterministic signature support

2024-11-26T14:03:34+01:00

So far, the test suite was silently passing for me, because it requires
either a patched version or a not-yet-released version of PuTTY to
actually run the tests against Pageant (which is the main beneficiary of
deterministic signature detection).  Actually plugging in a suitable
patched Pageant version revealed a couple of key places where we
silently assume that the key type alone determines its suitability for
`derivepassphrase`.  This commit rectifies that.
</pre>

Fix spurious overloaded signature mismatch

2024-11-26T13:23:33+01:00

</pre>

Indicate external links in non-API documentation as well

2024-11-26T13:21:54+01:00

</pre>

Split the SSH key how-to into how-to and reference documents

2024-11-26T00:32:29+01:00

Because the original how-to discussed both prerequisites and the how-to
of SSH keys, it was tonally inconsistent.  It makes much more sense from
a reading flow perspective to move the discussion of prerequisites into
a separate reference document and link to it from the how-to page.  So
do exactly that.

Relative to the old how-to page, the new prerequisites reference page
additionally includes sections on how to determine the SSH key type from
the algorithm name used in the wire protocol, and sample transcripts for
generating new SSH keys suitable for `derivepassphrase vault`; this is
based on feedback for the old how-to page.  The new how-to page also
shows the actual key selection dialog instead of only the command-line
to run.
</pre>

Make suitable SSH key listing easier to distinguish

2024-11-26T00:31:20+01:00

On the one hand, truncate and align the listing as two columns, not
three, by combining key type and (truncated) key data into one column.
For heterogenous lists with different key types, this nicely sets off
the comment column (which the user can change to help distinguish the
keys) from the key data (which the user cannot change).

On the other hand, if truncating the key data for the display, truncate
the *front* of the data, not the back.  For homogenous lists, this
generally leads to better distinguishable key listings: the front
contains information common to all keys (the wire-encoded key type), but
the back contains key-specific information (for RSA, Ed25519 and Ed448
keys at least).
</pre>