Recent commits to derivepassphrase.git (83df7001d8996914bbfa0beaea8402074c0acd05)

Highlight security warnings and risks more prominently in the docs

2024-12-19T15:04:11+01:00

</pre>

Make obtaining the compatibility config filename more explicit

2024-12-19T15:04:11+01:00

When obtaining the compatibility config filename `settings.json` from
`cli._config_filename`, rename the corresponding subsystem from
`settings` to `old settings.json`.  Furthermore, pass that explicit
subsystem upon each call.  This frees us up to change the default
subsystem in a future commit.

Because this is not a public function, this is not a change in the
public API.

Some reformatting is necessary.
</pre>

Merge topic branch 'usage-fixes' into master

2024-12-17T20:13:49+01:00

* t/usage-fixes:
  Fix user interface errors if the SSH agent does not work
  Fix usage of `--debug`, `--verbose` and `--quiet` options
</pre>

Fix user interface errors if the SSH agent does not work

2024-12-13T14:52:17+01:00

While the configuration and interactive selection of an SSH key is
properly guarded against (i.e., any exceptions are wrapped into proper
command-line error messages), the calls to `vault.Vault.phrase_from_key`
were not similarly guarded.  This has now been fixed.

The fix also uncovered an incorrectly specified mock function in the
test suite, which has been repaired as well.
</pre>

Fix usage of `--debug`, `--verbose` and `--quiet` options

2024-12-13T14:25:44+01:00

The three "verbosity" options `--debug`, `--verbose` and `--quiet` set
the logging level for `derivepassphrase`, globally.  Because `click`
does not support mutually exclusive options by default, these options
are implemented as boolean flags, and it is possible to override earlier
verbosity settings with later options.

The previous setup treated the three options as disjointed flags, so
each callback was called once, irrespective of the others, so the
aforementioned intended overriding behavior was not working properly.
In addition, the callback was faulty, always enabling each of the flags.

The new setup now links all three options to the same flag, with
different flag values.  We further expose the option objects at the top
level, and unify the three callback functions to a single one.

As a side effect, we also fix a misclassified diagnostic during
configuration file migration ("vault" derivation scheme).
</pre>

Merge topic branch 'hypothesis-fixes' into master

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

* t/hypothesis-fixes:
  Actually correctly implement custom hypothesis settings
  Overhaul the state machine for testing vault configuration imports
</pre>

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>

Merge topic branch 'import-override-mode' into master

2024-12-12T12:02:50+01:00

* t/import-override-mode:
  Allow the user to overwrite the current vault configuration
  Test config merging with partial service configs too
</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>