https://git.schokokeks.org/derivepassphrase.git/tree/5959cb77d6074f26c59cfe5342592aef52c94aee Recent commits feed provided by GitList. https://git.schokokeks.org/derivepassphrase.git/commit/5959cb77d6074f26c59cfe5342592aef52c94aee software@the13thletter.info (Marco Ricci) Wed, 27 Nov 2024 13:29:15 +0100 5959cb77d6074f26c59cfe5342592aef52c94aee This case was apparently forgotten when adding the 256- and 384-bit keys. https://git.schokokeks.org/derivepassphrase.git/commit/da7fed85c9fe23df9a0bba7da52389d0fdcb402f software@the13thletter.info (Marco Ricci) Wed, 27 Nov 2024 00:09:55 +0100 da7fed85c9fe23df9a0bba7da52389d0fdcb402f 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. https://git.schokokeks.org/derivepassphrase.git/commit/df33a1594cc2496e3858f3818cdab0f807d9ed88 software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 23:28:43 +0100 df33a1594cc2496e3858f3818cdab0f807d9ed88 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. https://git.schokokeks.org/derivepassphrase.git/commit/fdbea449cda2a00785dd803c43cf9dbec2995ba1 software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 14:26:21 +0100 fdbea449cda2a00785dd803c43cf9dbec2995ba1 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. https://git.schokokeks.org/derivepassphrase.git/commit/8a56dbdafab38d5493e1aee317f9fe7ec480c156 software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 14:12:53 +0100 8a56dbdafab38d5493e1aee317f9fe7ec480c156 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. https://git.schokokeks.org/derivepassphrase.git/commit/b5cb2824fdb57c10cc1021ebe284d33426824a28 software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 14:03:34 +0100 b5cb2824fdb57c10cc1021ebe284d33426824a28 https://git.schokokeks.org/derivepassphrase.git/commit/ba14c709ba5136482a88d3964e62755d155baf9f software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 13:23:33 +0100 ba14c709ba5136482a88d3964e62755d155baf9f https://git.schokokeks.org/derivepassphrase.git/commit/b630c463f6443e090f728d004ef34c8cdf5dc2c6 software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 13:21:54 +0100 b630c463f6443e090f728d004ef34c8cdf5dc2c6 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. https://git.schokokeks.org/derivepassphrase.git/commit/20931ed0c7a376df2fc2a19746a0ed96fe755ace software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 00:32:29 +0100 20931ed0c7a376df2fc2a19746a0ed96fe755ace 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). https://git.schokokeks.org/derivepassphrase.git/commit/29b26ee3335a21a4e5ef5760cc8b705456d8f78d software@the13thletter.info (Marco Ricci) Tue, 26 Nov 2024 00:31:20 +0100 29b26ee3335a21a4e5ef5760cc8b705456d8f78d