https://git.schokokeks.org/derivepassphrase.git/tree/c7d52b780ebed8175ef8238a2c811082b29403e6 Recent commits feed provided by GitList. This includes the 'pageant-deterministic-signatures' topic branch as well. * t/ssh-key-howto: Add missing tests for `SSHAgentClient.query_extensions` runtime errors Retire the use of symlinks for the README and the changelog Use canonical test keys in all SSH agent key listings Unmark icon- and badge-type external links as external Document that `is_suitable_ssh_key` now takes an optional agent client in the changelog Add an ecdsa-sha2-nistp521 SSH test key Publish polished `is_suitable_ssh_key` and `has_deterministic_dsa_signatures` interfaces Let the `running_ssh_agent` test fixture report the agent type Decouple deterministic signatures from general SSH agent detection Fix test suite to actually test deterministic signature support Fix spurious overloaded signature mismatch Indicate external links in non-API documentation as well Split the SSH key how-to into how-to and reference documents Make suitable SSH key listing easier to distinguish Add changelog entry for deterministic DSA/ECDSA signature support Add how-to for setting up an SSH key for `derivepassphrase vault` Purge the info badges for current Python or derivepassphrase versions Support the "all signatures are deterministic" feature of some SSH agents Support one-off SSH agent client child contexts https://git.schokokeks.org/derivepassphrase.git/commit/c7d52b780ebed8175ef8238a2c811082b29403e6 software@the13thletter.info (Marco Ricci) Thu, 28 Nov 2024 11:32:33 +0100 c7d52b780ebed8175ef8238a2c811082b29403e6 Currently, this is still a white-box, maliciously compliant design that relies heavily on implementation details of the function under test. That said, the failure cases being triggered here are all SSH agent protocol violations, which would otherwise be difficult to trigger in "real" SSH agents. https://git.schokokeks.org/derivepassphrase.git/commit/b725e5f10e6031cf0781c8593fe854b2046a3bae software@the13thletter.info (Marco Ricci) Wed, 27 Nov 2024 20:23:06 +0100 b725e5f10e6031cf0781c8593fe854b2046a3bae Symlinks interact very poorly with online git repository viewers, and while they are offline viewable on Unixish systems, readers only see the source view, not the rendered view. For the documentation frontpage `docs/index.md`, use the Snippets extension (Material for MkDocs/Python-Markdownx) to include the contents of `README.md`. This will allow future customization of the frontpage by either appending further content or only embedding parts of the README. For the changelog, because we use `scriv` to maintain it semi-automatically and thus want the changelog snippets to stay out of the top-level directory, we do not want `docs/changelog.md` to symlink to or to snippet-include the top-level `CHANGELOG.md`. Instead, we let `CHANGELOG.md` point to the `docs` directory (in prose), and purge the symlinks to the SVG badges. The original intent was to make the changelog renderable at the top-level, without the MkDocs machinery, but this is only really feasible if the changelog is handwritten, which hasn't been the case anymore for quite some time already. https://git.schokokeks.org/derivepassphrase.git/commit/70535b833256e31c5913e3decffc1706bb4ecd38 software@the13thletter.info (Marco Ricci) Wed, 27 Nov 2024 18:21:17 +0100 70535b833256e31c5913e3decffc1706bb4ecd38 For all documentation, whenever a formatted key listing of suitable keys is presented, use the test keys from the test suite if possible. Also, correct a typo. https://git.schokokeks.org/derivepassphrase.git/commit/adfb4e89b0a8b7e92e7b777c36fd68d51057f231 software@the13thletter.info (Marco Ricci) Wed, 27 Nov 2024 15:10:52 +0100 adfb4e89b0a8b7e92e7b777c36fd68d51057f231 Icon-/badge-only external links lose their visual succintness if they include the external link marker afterwards. Also use this opportunity to rewrite the external links CSS selectors using the `:is` and `:has` pseudo-classes, which leads to much less code repetition. Supposedly, every major browser has had a release with `:has` support since December 2023, so browser compatibility shouldn't be a major issue. https://git.schokokeks.org/derivepassphrase.git/commit/54f1edfb13a587ccccba30254a52b75d7387d4ad software@the13thletter.info (Marco Ricci) Wed, 27 Nov 2024 14:16:59 +0100 54f1edfb13a587ccccba30254a52b75d7387d4ad 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