Recent commits to derivepassphrase.git (7189e0e3b7eb053181c6a28cc585c7c4aebb6ee7)

Actually correctly implement custom hypothesis settings

2024-12-12T12:03:30+01:00

The `hypothesis.settings` decorators are intended to modify the
currently active `hypothesis` settings profile for singular tests.
However, the profiles are defined and selected only *after* the `tests`
module has been loaded, so any settings defined in the `tests` module
actually modify the `hypothesis` default settings, not the selected
profile's settings.

Fix this by defining decorators that construct and apply the correct
settings, which defines the settings objects deferredly, instead of
defining them immediately.
</pre>

Overhaul the state machine for testing vault configuration imports

2024-12-12T12:03:30+01:00

Redesign the state machine for testing vault configuration imports, and
the `hypothesis` generation strategies for vault configurations, to
overcome the following problems with the old design:

 1. Data generation of vault configurations needs many redraws, because
    we express dependencies by rejecting the whole tuple of properties
    if it doesn't match.  We could instead draw the independent
    properties, and conditional on their values, draw the dependent
    ones; cf. Gibbs sampling vs. rejection sampling.

 2. `hypothesis` implements state machine rule selection as drawing from
    a list of eligible rules.  This list must remain static during
    redrawing and backtracking, lest `hypothesis` complains the test is
    flaky.  While it isn't expressly forbidden to store state manually
    in the state machine, the old design made the list of eligible
    rules dependent on the implicit machine state and on the generated
    values, in a way that led to flakiness.

Fix these issues by doing the following:

  - Rename the class from `ConfigMergingStateMachine` to
    `ConfigManagementStateMachine`, because it's no longer just about
    merging configurations.

  - Implement strategies to build a full vault configuration from
    multiple full settings configurations, and a partial settings
    configuration from a full settings configuration.  Draw
    interactively, first the independent properties, then the dependent
    ones.  This tackles issue (1).

  - Overhaul the state machine, effectively rewriting it from scratch,
    by managing all state in `hypothesis` bundles.  Ensure the bundles
    are filled at initialization, and that each (non-bookkeeping) rule
    begins with storing the configuration and ends with checking and
    returning the transformed configuration.  Filter the values drawn
    from the bundles, instead of filtering the rule set based on the
    machine's current state.  This tackles issue (2) above.

The resulting state machine should have an acceptable drawing success
rate (without needing to override the `filter_too_much` `hypothesis`
health check), at the cost of slow(ish) drawing speed and slow(er)
execution speed because the configuration must be replayed onto disk
during each step.  On the other hand, the single steps now are more
repeatable and more independent of each other.

This implementation makes use of several top-level functions and
constants, outside of the state machine class.  Attempting to use static
and class methods instead leads to messy workarounds because of the name
resolution rules and because of mismatches in the calling conventions of
static and class methods during class definition vs. during execution
time.  In the end, the "top-level functions and constants" version is
the most straight-forward to read.
</pre>

Allow the user to overwrite the current vault configuration

2024-12-12T11:59:47+01:00

In the "vault" derivation scheme, commands that edit or import
a configuration actually merge with the existing configuration, for
compatibility with the original vault(1).  However, sometimes it is
desired to replace the existing configuration instead, when importing
or when setting a (service or global) configuration.  We introduce a new
`--overwrite-existing` command-line option that signals exactly that,
and a `--merge-existing` option which signals the (previously implicit)
default merging behavior.
</pre>

Test config merging with partial service configs too

2024-12-12T11:59:47+01:00

Using larger numbers of settings (and services) leads to a very low
probability of actually finding a viable path of action in the state
machine; the run is a no-op, save for the initial setup.  Presumably, we
need a larger pool of readily-assembled and/or more cross-compatible
objects, instead of the stepwise approach employed here with service
names, settings, and configurations.  This needs to be addressed in
a future commit, however.
</pre>

Merge topic branch 'pageant082' into master

2024-12-09T11:36:00+01:00

* t/pageant082:
  Explicitly support Pageant 0.82 in the test suite

GitHub: Closes #14.
</pre>

Explicitly support Pageant 0.82 in the test suite

2024-12-09T11:30:59+01:00

Pageant 0.82, released two weeks ago, supports both proper output buffer
flushing and a "foreground" mode.  Foreground mode is used to correctly
isolate a spawned Pageant instance in the test suite.  The test for
Pageant's suitability can now be simplified to whether it is at least
version 0.82, or not.

Furthermore, because no published version of Pageant supports only
proper output buffer flushing but not foreground mode, it is no longer
necessary to arrange for debug output to be silently discarded.  This
further simplifies SSH agent handling considerably.

Finally, we fix various mistakes in the documentation of the testing
machinery.
</pre>

Clean up "docs" hatch environment, also subsuming "release"

2024-12-08T19:06:33+01:00

</pre>

Merge topic branch 'logging' into master

2024-12-08T19:03:08+01:00

* t/logging:
  Document the switch to the logging and warning systems in the changelog
</pre>

Document the switch to the logging and warning systems in the changelog

2024-12-08T19:02:03+01:00

</pre>

Refactor code to run under Python 3.9's LL(1) parser

2024-12-08T17:44:25+01:00

Though it does not do so by default, Python 3.9 can run with the old
LL(1) parser instead of the PEG-based parser.  Most importantly, the
LL(1) parser does not support parenthesized context manager expressions,
and this is why they have only become officially supported in Python
3.10, once the PEG-based parser became mandatory.  Therefore, for
compatibility, we replace every "proper" parenthesized context manager
expression with equivalent explicit use of a `contextlib.ExitStack`, and
every degenerate such expression by removing the parentheses.

We now also explicitly test `derivepassphrase` with the LL(1) parser,
for as long as Python 3.9 remains supported.

While the use of a `contextlib.ExitStack` comes with additional runtime
cost, by a lucky coincidence, all such proper usage of parenthesized
context manager expressions is confined to the test suite, where we
really don't care too much about slightly higher runtimes if it buys us
more clarity, correctness and compatibility instead.
</pre>