Recent commits to derivepassphrase.git (38696145b173f7194217caacf15bd28d4b15d40b)

Fix missing Python version classifier

2024-10-16T00:43:03+02:00

</pre>

Implement feedback on the basic setup (passphrase) tutorial

2024-10-16T00:29:21+02:00

Fix typos and outdated command output.  Add a (hidden by default) short
explanation, mnemonic and examples for the `--repeat` option, which
actually denotes maximum consecutive occurrence, not additional allowed
repetitions.
</pre>

Release 0.3.0

2024-10-15T13:46:21+02:00

</pre>

Merge topic branch 'vault-config-amending' into master

2024-10-15T13:16:27+02:00

* t/vault-config-amending:
  Add changelog entry summarizing new warnings emitted
  Add changelog entry for the new amending/merging config import behavior
  Warn the user upon supplying an empty service name
  Add a stateful hypothesis test for config importing and merging
  Fix missing consideration of key and phrase both being specified
  Fix clean up of falsy "length" and "repeat" settings
  Correctly model vault global and service settings
  Move vault service config generation to top-level tests module
  Align behavior with vault concerning config imports

GitHub: Closes #16.
</pre>

Add changelog entry summarizing new warnings emitted

2024-10-15T13:15:38+02:00

</pre>

Add changelog entry for the new amending/merging config import behavior

2024-10-15T13:07:09+02:00

</pre>

Warn the user upon supplying an empty service name

2024-10-15T12:47:49+02:00

The `derivepassphrase` command-line largely, and vault(1) completely,
treats an empty service name the same as if no service name had been
supplied, switching over to global operation instead of service-specific
operation (or erroring out in case a service must be given).  For
`derivepassphrase`, this is mostly a user interface issue – the
underlying machinery supports empty service names –, but kept for
compatibility with vault(1).  However, this is very easy to diagnose,
and the user would benefit from seeing a warning about a seemingly
omitted service name.  So do that, and issue a warning upon encountering
an empty service name on the command-line or in an imported
configuration.  (The warning message changes slightly in each case.)

Also, add explicit tests for these two scenarios that trigger the
warning.
</pre>

Add a stateful hypothesis test for config importing and merging

2024-10-15T11:22:02+02:00

The state machine underlying this stateful hypothesis test constructs
random vault settings objects and random service names, then merges
these together into full configurations and imports those.
Alternatively, it sets or purges single-service or global settings.
The machine then checks after each step that the nominal, current
configuration matches the actual configuration stored by
`derivepassphrase`.  The program runs with a temporary settings
directory for the duration of the state machine run.

Unlike how a fully general state machine for this task would probably
run, *this* state machine does not filter its steps based on the list of
services currently stored in the configuration, but rather on the full
list of known service names.  (Evaluating a hypothesis search strategy
based on the current contents of an instance variable appears to be
a very non-straight-foward ordeal, if not outright impossible.)  As
a consequence, the "purge" action may actually be a no-op, and the "set"
action may actually be a "create" action.  While this *could* be
implemented with `hypothesis.assume`, presumably this would have such
a low success probability that it triggers health check errors.
</pre>

Fix missing consideration of key and phrase both being specified

2024-10-14T23:14:09+02:00

In 798ddc103c6c03835394733aeca128b970aacd06, we permitted both key and
phrase to be specified when importing a configuration.  However, the
code for updating or setting a stored global or service configuration
was still purging the key or the phrase setting if the other was being
set.  Additionally, the currently effective settings and the new
settings object were being incorrectly calculated, and none of the tests
were actually specifically testing this.  So fix all of these.

When setting the new settings object, we issue a warning if we are newly
configuring a passphrase but a key is effectively set; the key will
override the passphrase unconditionally.

Since there are now a couple of (harmless) warning messages that will be
emitted for weird or problematic inputs, and which are therefore likely
and sometimes necessary to trigger during tests, add a new function to
classify warnings as "harmless and expected" or not.  This keeps the
test code for successfully calling `derivepassphrase vault` still
reasonably short and readable.  It also keeps this test code generic, so
that we needn't defensively code around situations where the input is
being programmatically generated and may or may not trigger these kinds
of warnings.
</pre>

Fix clean up of falsy "length" and "repeat" settings

2024-10-14T23:11:27+02:00

A falsy length behaves like the standard length, and a falsy repeat
setting forces(!) repetition to be disregarded.  So the former
normalizes to 20 and the latter to 0, regardless of any inherited
setting.  In both cases, we can't just remove the setting, we need to
explicitly set the default value.

(For repeat settings, and upper and lower etc. settings too, there's an
additional twist: the value `0.0` (float) is equivalent to `0` (int),
but the former is a type violation.  This means we need to also make
sure to check the type when normalizing, not just the value.)
</pre>