https://git.schokokeks.org/derivepassphrase.git/tree/16068a30b5fbbeb0b8624c52ac664911b24b83f4Recent commits to derivepassphrase.git (16068a30b5fbbeb0b8624c52ac664911b24b83f4)2024-10-15T13:07:09+02:00tag:gitlist.org,2012:commit/16068a30b5fbbeb0b8624c52ac664911b24b83f4Add changelog entry for the new amending/merging config import behavior2024-10-15T13:07:09+02:00Marco Riccisoftware@the13thletter.info
<pre></pre>
tag:gitlist.org,2012:commit/c1bf00eadd1bf733ac25a25eafbe110d61936c54Warn the user upon supplying an empty service name2024-10-15T12:47:49+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/eb2e29c26a1baf9c59d6ed5dfa787b9902e5bb4fAdd a stateful hypothesis test for config importing and merging2024-10-15T11:22:02+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/23177a3206f5c0b4220d8ee496f887ed7e8cb0abFix missing consideration of key and phrase both being specified2024-10-14T23:14:09+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/c9faa4d734f4d6edf148e6284e51e9e48826cc35Fix clean up of falsy "length" and "repeat" settings2024-10-14T23:11:27+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/9713343438217b44f3eb408b54f0d17f8baca64aCorrectly model vault global and service settings2024-10-14T22:31:40+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/33b76f6b4d547cc056753aa3b73294683b68946eMove vault service config generation to top-level tests module2024-10-14T22:20:29+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/02e015e8ba265b4f82bac3815db93be2188a6bbcAlign behavior with vault concerning config imports2024-10-13T14:39:43+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/3ad62c4d59c6d54fb86b2774919b2f71713eecaeTrigger InvalidSignature exceptions in storeroom exporter tests2024-10-10T12:36:24+02:00Marco Riccisoftware@the13thletter.info
<pre>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>
tag:gitlist.org,2012:commit/837e57d2ce6c317d5ba483d88baddbdccfae03dfAdd remaining tests to the storeroom exporter for 100% coverage2024-10-10T12:18:23+02:00Marco Riccisoftware@the13thletter.info
<pre>Before this commit, certain consistency checks within the storeroom
exporter that seemed difficult to test remained untested: a payload size
check in the master keys decryption routine, another payload size check
in the session keys decryption routine, and object connectivity and type
correctness checks in the top-level exporter routine.
The master and session keys decryption routines, it turns out, don't
need this explicit size check: the `struct` library, used for decoding
the payload even further, already checks this automatically. (What *is*
needed is a wrapper to convert the exception type, in general, for the
whole decryption block.)
For the connectivity and type correctness checks in the top-level
exporter routine, I generated another couple of broken storeroom
configurations (e.g. where directory contents, encoded as a JSON array,
contain non-string elements). We now test for each of these
configurations if they correctly fail to parse.
Finally, it turns out that many of the docstrings reported the
ciphertext sizes incorrectly, because they wrongly neglected the
padding in their calculations. Fix this, of course.
</pre>