Recent commits to derivepassphrase.git (e6710afcce476a8b4301ce49846b44fd6cf714f2)

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>

Correctly model vault global and service settings

2024-10-14T22:31:40+02:00

Excluding extensions due to `derivepassphrase`, in vault(1), the service
settings are a superset of the global settings… though some settings
might be weird in a global setting.  The abstract data types don't
accurately model this, though.  So fix those.

(The sole current `derivepassphrase` extension, the
`unicode_normalization_form` setting, modifies the `phrase` setting, and
so also makes sense to specify globally or locally.  So use the same
inheritance and scoping rules as `phrase`.)

Incidentally, the command-line interface did not respect this
inheritance either… in a more destructive way, asserting that some
options require a service when they don't, or don't take a service when
they do.  Redo the categorization there into three groups instead of
two: service name mandatory, forbidden, or optional (new).
</pre>

Move vault service config generation to top-level tests module

2024-10-14T22:20:29+02:00

The generation of vault service configurations is not inherently tied to
the `vault` module only; the CLI also requires its use.  So move it to
a more central location.
</pre>

Align behavior with vault concerning config imports

2024-10-13T14:39:43+02:00

When importing a configuration, the original vault(1) does not replace
its configuration as a whole with the supplied one.  Instead, each
"section" of the new configuration – the global settings, and each named
service's settings – replaces the corresponding section in the old
configuration, if any.  Any sections not mentioned in the new
configuration are left untouched; in particular, existing service
settings are *kept* if they are not mentioned in the new configuration.

`derivepassphrase` uses a simpler, database-like dump/restore model,
overwriting the whole old configuration with the new one.  As
a consequence, old services settings are *dropped* if they are not
mentioned in the new configuration.  This behavior is a visible
deviation from vault(1), and shall thus be removed.

This commit contains the necessary changes to the import machinery to
correctly calculate the new, merged configuration.  Surprisingly, this
already passes all tests, which is more a sign that our tests are
incomplete rather than that the code is robust against this failure
type.  So, in upcoming commits we will introduce functional tests for
the config import/merging machinery second, and bugfixes for other
things we uncovered while writing these functional tests first.
</pre>

Trigger InvalidSignature exceptions in storeroom exporter tests

2024-10-10T12:36:24+02:00

So far, we haven't been explicitly testing for whether the master and
session keys decrytion routines correctly reject payloads with invalid
MAC values, and with the correct error type.  Surely the `cryptography`
primitive is implemented correctly, but there was no test whether
*we* were using the primitive correctly.  So, add one.
</pre>