https://git.schokokeks.org/derivepassphrase.git/tree/e6710afcce476a8b4301ce49846b44fd6cf714f2 Recent commits feed provided by GitList. https://git.schokokeks.org/derivepassphrase.git/commit/e6710afcce476a8b4301ce49846b44fd6cf714f2 software@the13thletter.info (Marco Ricci) Tue, 15 Oct 2024 13:15:38 +0200 e6710afcce476a8b4301ce49846b44fd6cf714f2 https://git.schokokeks.org/derivepassphrase.git/commit/16068a30b5fbbeb0b8624c52ac664911b24b83f4 software@the13thletter.info (Marco Ricci) Tue, 15 Oct 2024 13:07:09 +0200 16068a30b5fbbeb0b8624c52ac664911b24b83f4 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. https://git.schokokeks.org/derivepassphrase.git/commit/c1bf00eadd1bf733ac25a25eafbe110d61936c54 software@the13thletter.info (Marco Ricci) Tue, 15 Oct 2024 12:47:49 +0200 c1bf00eadd1bf733ac25a25eafbe110d61936c54 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. https://git.schokokeks.org/derivepassphrase.git/commit/eb2e29c26a1baf9c59d6ed5dfa787b9902e5bb4f software@the13thletter.info (Marco Ricci) Tue, 15 Oct 2024 11:22:02 +0200 eb2e29c26a1baf9c59d6ed5dfa787b9902e5bb4f 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. https://git.schokokeks.org/derivepassphrase.git/commit/23177a3206f5c0b4220d8ee496f887ed7e8cb0ab software@the13thletter.info (Marco Ricci) Mon, 14 Oct 2024 23:14:09 +0200 23177a3206f5c0b4220d8ee496f887ed7e8cb0ab 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.) https://git.schokokeks.org/derivepassphrase.git/commit/c9faa4d734f4d6edf148e6284e51e9e48826cc35 software@the13thletter.info (Marco Ricci) Mon, 14 Oct 2024 23:11:27 +0200 c9faa4d734f4d6edf148e6284e51e9e48826cc35 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). https://git.schokokeks.org/derivepassphrase.git/commit/9713343438217b44f3eb408b54f0d17f8baca64a software@the13thletter.info (Marco Ricci) Mon, 14 Oct 2024 22:31:40 +0200 9713343438217b44f3eb408b54f0d17f8baca64a 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. https://git.schokokeks.org/derivepassphrase.git/commit/33b76f6b4d547cc056753aa3b73294683b68946e software@the13thletter.info (Marco Ricci) Mon, 14 Oct 2024 22:20:29 +0200 33b76f6b4d547cc056753aa3b73294683b68946e 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. https://git.schokokeks.org/derivepassphrase.git/commit/02e015e8ba265b4f82bac3815db93be2188a6bbc software@the13thletter.info (Marco Ricci) Sun, 13 Oct 2024 14:39:43 +0200 02e015e8ba265b4f82bac3815db93be2188a6bbc 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. https://git.schokokeks.org/derivepassphrase.git/commit/3ad62c4d59c6d54fb86b2774919b2f71713eecae software@the13thletter.info (Marco Ricci) Thu, 10 Oct 2024 12:36:24 +0200 3ad62c4d59c6d54fb86b2774919b2f71713eecae