https://git.schokokeks.org/derivepassphrase.git/tree/0393fa2adc5818edd9b9f99eb9bc308eb8cd066eRecent commits to derivepassphrase.git (0393fa2adc5818edd9b9f99eb9bc308eb8cd066e)2026-01-18T17:35:34+01:00tag:gitlist.org,2012:commit/0393fa2adc5818edd9b9f99eb9bc308eb8cd066eFor interfaced SSH agents in the tests, set SSH_AUTH_SOCK manually2026-01-18T17:35:34+01:00Marco Riccisoftware@the13thletter.info
<pre>Generally, if we have an abstract socket connected to an SSH agent, then
this is sufficient for us to construct a client based on the socket,
and interact with the agent as needed.
However, in the CLI tests, there are situations where we are
orchestrating the whole `derivepassphrase` application, and the
application must connect to the agent itself. For these situations, we
need to set up the necessary configuration to pass the agent's socket
address to `derivepassphrase`. For agents merely interfaced in the test
suite, we were not doing such a setup, causing orchestrated
`derivepassphrase` application instances to believe there was no agent
to connect to.
Fix this by (a) exposing the socket address on the socket object,
internal to the spawning/interfacing function, and (b) let interfacing
functions return a pair of socket and socket address, not just the
socket. (We intend to keep the interface for actually obtaining the
address private to each interfacing function, because not all socket
objects can easily be retrofitted with extra methods to query the socket
address.)
(As a side effect, give the socket providers on The Annoying OS more
specific typing, so that the type checker can verify that the
interfacing functions are accessing the correct attributes and methods
for obtaining the socket address.)
</pre>
tag:gitlist.org,2012:commit/6941e00680b380839a5b2c05783a8240ac5b77c1Use the "correct" wrong SSH_AUTH_SOCK value2026-01-18T16:37:36+01:00Marco Riccisoftware@the13thletter.info
<pre>Some tests require a wrong SSH_AUTH_SOCK value where no SSH agent can be
listening, but which is nonetheless syntactically valid. Since Windows
named pipes have a specific address format, syntactically valid but
wrong values look different on The Annoying OS than they look on POSIX.
So fill in wrong values OS-specifically, not generally: on POSIX, we use
what is clearly a directory, and on The Annoying OS, we use the common
pipe name prefix (which is also a directory).
</pre>
tag:gitlist.org,2012:commit/0d071d0ac2663006f7c5dff2f337e3e91d636fd4Prioritize WindowsNamedPipesNotAvailableError over other errors2026-01-18T15:42:53+01:00Marco Riccisoftware@the13thletter.info
<pre>The SSH agent socket provider, by contract, must raise
`NotImplementedError` (or a subclass) if and only if the socket can
never be successfully constructed, on principle. Conversely, if the
socket provider raises any other kind of error, then the socket *could*
be constructed on this system, principally.
In the specific case of Windows named pipes whose address is named by
the `SSH_AUTH_SOCK` environment variable, it is a programming error to
first check the environment variable value, allowing `KeyError` or
`ValueError` to bubble through to the caller, and only afterwards during
construction of the named pipe realize that there is no support.
</pre>
tag:gitlist.org,2012:commit/561a479916d0cea8312ce0aee02889bd5297107fFix coverage slipups and error messages in the Windows named pipe handles2026-01-18T14:38:27+01:00Marco Riccisoftware@the13thletter.info
<pre></pre>
tag:gitlist.org,2012:commit/5ade48e3fcfe03b9fdb2651e80a08a9360ccbc0cFix coverage slipup of socket provider alias registration2026-01-18T14:25:44+01:00Marco Riccisoftware@the13thletter.info
<pre>When registering auto-detected new socket providers, registration should
fail if two different providers try to register the same alias.
The test suite originally contained a test case for this, but it used
the "posix" and "the_annoying_os" names as base names, which were
changed to aliases in 41029a5e6ef04a9870dcaf044b54a26af94260ab. Thus,
the test *actually* attempted to register something that was previously
an alias as a new base name. This was also an error (still is), and it
used the same error message, so the test continued to pass. But it was
then exercising a different code branch, and thus the original code
branch was effectively lacking a dedicated test.
We fix this by resolving the now-aliased entry to its actual base name.
</pre>
tag: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>