https://git.schokokeks.org/derivepassphrase.git/tree/f1653ee4bd35f594c1dadc54d7413c7a5233db5dRecent commits to derivepassphrase.git (f1653ee4bd35f594c1dadc54d7413c7a5233db5d)2026-01-18T14:23:57+01:00tag:gitlist.org,2012:commit/f1653ee4bd35f594c1dadc54d7413c7a5233db5dProperly combine coverage files cross-platform2026-01-18T14:23:57+01:00Marco Riccisoftware@the13thletter.info
<pre>Set the coverage settings to record relative paths, instead of absolute
ones, so that when combining coverage files from different OSes, the
paths merge cleanly.
</pre>
tag:gitlist.org,2012:commit/7a5b6f099399315c35113a963906077788d8fd36Use the SSH_AUTH_SOCK socket provider as "native" also on The Annoying OS2026-01-18T14:14:04+01:00Marco Riccisoftware@the13thletter.info
<pre>Pageant is a good *fallback* native socket provider, but a bad
*preferred* native socket provider, because the address is not
configurable. Using `ssh_auth_sock_on_the_annoying_os` as the preferred
native socker provider instead allows the user to easily change the
agent to talk to by switching out environment variables.
</pre>
tag:gitlist.org,2012:commit/d89c86a3394b8711b555725cda8031ba15fddd99Distinguish process-spawning heavy-duty tests from other heavy-duty tests2026-01-17T19:40:14+01:00Marco Riccisoftware@the13thletter.info
<pre>Give heavy-duty tests that involve spawning processes less extensive
example counts, because spawning processes is expensive (especially on
The Annoying OS), and because Python 3.14+ is defaulting to
slow-but-safe process spawning machinery that make these costs much more
visible than before.
Specifically, we introduce new hypothesis machinery for calculating
a good `max_example` count for state machines that involve spawning
processes on each state transition. There is currently only one such
state machine: `FakeConfigurationMutexStateMachine` from the CLI
heavy-duty tests. The example count `n'` for state machines is then
`sqrt(10 * n)`, where `n` is the example count for other test types.
For the "dev", "default" and "intense" profiles (`n = 10`, `100` and
`1000`, respectively), this translates to `n' = 10`, `31` and `100`,
respectively. In particular, at "dev" they are identical, and at
"intense", state machines have "default" behavior.
In preparation for this commit, we noticed that the hypothesis settings
profiles were not necessarily defined when the state machines query the
settings. Accordingly, we moved the settings profiles setup into the
`tests.machinery.hypothesis` package, made it idempotent, and ensured it
would be called before accessing the profiles.
</pre>
tag:gitlist.org,2012:commit/3cf1d6dcec03d2e186c6f77230e2157c9c76c48dUse "loadgroup" scheduling in the test suite runner2026-01-17T19:00:49+01:00Marco Riccisoftware@the13thletter.info
<pre>Parallelize the test suite via the "loadgroup" scheduler, instead of the
"worksteal" scheduler. There is currently only one `xtest_group` marker
value, so effectively, the scheduler schedules the *marked* tests all to
the same worker, and the others in whatever manner. We can thus rely on
the marked tests executing serially, and do not need locks to protect
them (or their fixture calls) from concurrent access.
This eliminates "locking implementations" as both a source of errors and
as another group of code that needs debugging, testing, and coverage.
(Which was, unfortunately, our experience with the `filelock` package we
used to protect non-isolated SSH agents on The Annoying OS during
fixture setup and teardown.)
As a bonus, because the "loadgroup" scheduler lazily assigns work items
as other items are completed, the performance is similar to the
"worksteal" scheduler it is replacing.
</pre>
tag:gitlist.org,2012:commit/dcfe53e7de00532eb56cfea5b429b91ff97dac32Add more coverage and linting exclusions related to Windows named pipes2026-01-04T22:40:37+01:00Marco Riccisoftware@the13thletter.info
<pre>Some of the missing exclusions are typos.
Others are accidental omissions due to writing the code for one platform
(POSIX-ish systems) without actually *testing* on that platform, because
the main logic is geared towards a different platform (here, The
Annoying OS) and was developed there. This especially concerns code
that is designed to never be called and which immediately throws an
exception upon being called: it is easy to forget the coverage exclusion
if the corresponding code path is never actually run.
Finally, other exclusions and code refactorings are due to the fact that
the static type checking interface for `ctypes` (i.e., the typing stubs
from the `typeshed` project) is vastly different for different operating
systems. So, type checking code on POSIX-ish systems that uses `ctypes`
for The Annoying OS's facilities causes the type checker to complain
about *a lot* of undefined symbols that `ctypes` supposedly does not
expose. For some commonly-used symbols with many call sites, it is
worth defining a dual wrapper/stub function (wrapper for supported OSes,
stub for others) to both silence the type checker's complaints about
"undefined symbols" and to not sacrifice too much readability.
(While the type checker supports branching on the current OS, this
drastically increases the number of branches to cover, or alternatively,
the number of coverage branch exceptions/exclusions to mark up. We
would be trading type checking exclusions for coverage branch
exclusions, gaining nothing.)
Finally finally, because The Annoying OS uses a very incompatible naming
scheme in its standard library, we need many linting exceptions for
variable, function and function argument naming.
</pre>
tag:gitlist.org,2012:commit/acf65003ef9c94345cb56a65f96d0e3cd427a62cFix SSH agent spawning on POSIX in the test suite2026-01-04T22:06:26+01:00Marco Riccisoftware@the13thletter.info
<pre>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.
</pre>
tag:gitlist.org,2012:commit/58bf123a7361c367d7aff10a9ad15abfe3284d27Use "overlapped I/O" for Windows named pipe communication2025-12-28T18:53:33+01:00Marco Riccisoftware@the13thletter.info
<pre></pre>
tag:gitlist.org,2012:commit/f08846edf1c9a3e79c5de70d8700b71f47608c1eFix the fallback variant of the Windows named pipe handling code2025-12-28T18:47:21+01:00Marco Riccisoftware@the13thletter.info
<pre>The fallback implementation for systems other than The Annoying OS was
incomplete.
</pre>
tag:gitlist.org,2012:commit/88d5ab66d69ab70ad62ee5fe660761a4737ea543Retry connecting to a named pipe if the pipe is busy2025-12-28T12:05:37+01:00Marco Riccisoftware@the13thletter.info
<pre>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`.
</pre>
tag:gitlist.org,2012:commit/00c90d7a6177bdb0cdd01580fd2e45351b82e526Do not suppress OSError when constructing Windows named pipes in test fixtures2025-12-27T18:52:29+01:00Marco Riccisoftware@the13thletter.info
<pre>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).
</pre>