https://git.schokokeks.org/derivepassphrase.git/tree/acf65003ef9c94345cb56a65f96d0e3cd427a62c Recent commits feed provided by GitList. If the `executable` passed to the `spawn_named_agent` function is `None`, we now correctly locate the agent in `PATH` using its default name, for all our SSH agent spawning functions. This was advertised to work this way when we introduced SSH agent interfacing functions in the test suite in 41029a5e6ef04a9870dcaf044b54a26af94260ab and updated the `spawn_named_agent` signature to match in 6340b5a541970c9d00ee653926102657028de309, but was never actually implemented, until now. Prior to 6340b5a541970c9d00ee653926102657028de309, the `executable` argument to `spawn_named_agent` was both a registry key and the basename of the executable to call, to be located in `PATH`. In that scheme, a `None` value meant that there was no external executable to spawn, so the agent-specific spawning functions would return a failure code. In 6340b5a541970c9d00ee653926102657028de309, the interpretation was changed to an "override" path: a string value for `executable` meant "use this path for the executable", a `None` value meant "use the default name, and locate the executable in `PATH`". But the corresponding *logic* for the `None` value case, i.e., searching `PATH`, was never actually implemented. Because none of the standard agent spawning/interfacing function definitions made use of this override mechanism, all SSH agent spawning functions were silently breaking, flatly claiming that the agents were not available even though they actually might have been. Furthermore, because this code refactoring was developed on The Annoying OS, where all current SSH agents are interfaced, not spawned, this failure went completely unnoticed. Now, while double-checking that the new Annoying-OS-specific code also works on POSIX, this misbehavior of the SSH agent spawning logic became apparent again, because on POSIX we *do* have agents that are spawned, not merely interfaced. So reintroduce the logic to locate the (default) executable if the path is not overriden. https://git.schokokeks.org/derivepassphrase.git/commit/acf65003ef9c94345cb56a65f96d0e3cd427a62c software@the13thletter.info (Marco Ricci) Sun, 04 Jan 2026 22:06:26 +0100 acf65003ef9c94345cb56a65f96d0e3cd427a62c https://git.schokokeks.org/derivepassphrase.git/commit/58bf123a7361c367d7aff10a9ad15abfe3284d27 software@the13thletter.info (Marco Ricci) Sun, 28 Dec 2025 18:53:33 +0100 58bf123a7361c367d7aff10a9ad15abfe3284d27 The fallback implementation for systems other than The Annoying OS was incomplete. https://git.schokokeks.org/derivepassphrase.git/commit/f08846edf1c9a3e79c5de70d8700b71f47608c1e software@the13thletter.info (Marco Ricci) Sun, 28 Dec 2025 18:47:21 +0100 f08846edf1c9a3e79c5de70d8700b71f47608c1e In the `WindowsNamedPipeHandle` constructor, if connecting the named pipe fails with the Windows error 231 (`ERROR_PIPE_BUSY`), retry the operation. (For expected future compatibility, we treat `BlockingIOError` the same way.) This behavior roughly corresponds to how system calls on POSIX should usually be retried if they return with `EINTR`. https://git.schokokeks.org/derivepassphrase.git/commit/88d5ab66d69ab70ad62ee5fe660761a4737ea543 software@the13thletter.info (Marco Ricci) Sun, 28 Dec 2025 12:05:37 +0100 88d5ab66d69ab70ad62ee5fe660761a4737ea543 Let any OSError that occurs when opening the named pipe bubble to the top of the test fixture, instead of suppressing it and indicating that the named pipe is unavailable. At the top level, the test fixture can then incorporate the error text into the failure or skip message (which would otherwise be invisible if suppressed further down). https://git.schokokeks.org/derivepassphrase.git/commit/00c90d7a6177bdb0cdd01580fd2e45351b82e526 software@the13thletter.info (Marco Ricci) Sat, 27 Dec 2025 18:52:29 +0100 00c90d7a6177bdb0cdd01580fd2e45351b82e526 In particular, pay consideration to interfaced agents, not just spawned ones. https://git.schokokeks.org/derivepassphrase.git/commit/ea42999f28cba570fc5954628bea71998cd7692a software@the13thletter.info (Marco Ricci) Sat, 27 Dec 2025 18:42:06 +0100 ea42999f28cba570fc5954628bea71998cd7692a When reacting to failures uploading a test key into an agent, both the agent type `KnownSSHAgent.UNIXPageant` and the type `KnownSSHAgent.Pageant` should be treated the same. However, the `ssh_agent_client_with_loaded_test_keys` only treated the former agent type specially. Now it also treats the latter type the same. https://git.schokokeks.org/derivepassphrase.git/commit/d63d93b230f23dbbfbb2eff0209cb3d076980b42 software@the13thletter.info (Marco Ricci) Sat, 27 Dec 2025 18:26:50 +0100 d63d93b230f23dbbfbb2eff0209cb3d076980b42 Instead of iterating over all test keys and testing whether the agent is not isolated and the key is a successfully loaded key, first check whether the agent is isolated or not, *then* iterate over the successfully loaded key names and extract the relevant test key from the test key table. The efficiency per operation is similar, but the previous setup always iterated the whole test key table unconditionally, whereas the new setup only iterates the successfully loaded key name set (fewer entries than the test key table), and only conditionally. https://git.schokokeks.org/derivepassphrase.git/commit/ff4e9ae1d2b3291b9606c270c8b03404307e045a software@the13thletter.info (Marco Ricci) Sat, 27 Dec 2025 17:33:06 +0100 ff4e9ae1d2b3291b9606c270c8b03404307e045a Add docstrings to the `_prepare_payload` and `_load_key_optimistically` helper functions. Also change the signature of `_load_key_optimistically` to take the test key structure directly, instead of taking a (dict) key to lookup the structure. (These types of things become apparent when writing docstrings, even for otherwise internal functions.) https://git.schokokeks.org/derivepassphrase.git/commit/02be2f8d25e96969ea375b67c34a01d2daf9c1b3 software@the13thletter.info (Marco Ricci) Sat, 27 Dec 2025 17:19:38 +0100 02be2f8d25e96969ea375b67c34a01d2daf9c1b3 https://git.schokokeks.org/derivepassphrase.git/commit/8f2c55735196b72cb4e305c53c14973c39048b8e software@the13thletter.info (Marco Ricci) Sat, 27 Dec 2025 17:10:07 +0100 8f2c55735196b72cb4e305c53c14973c39048b8e