https://git.schokokeks.org/derivepassphrase.git/tree/71c3866eef5deae63ad66f0100c5bf294917a749 Recent commits feed provided by GitList. https://git.schokokeks.org/derivepassphrase.git/commit/71c3866eef5deae63ad66f0100c5bf294917a749 software@the13thletter.info (Marco Ricci) Tue, 15 Oct 2024 13:46:21 +0200 71c3866eef5deae63ad66f0100c5bf294917a749 * 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. https://git.schokokeks.org/derivepassphrase.git/commit/7d6ac080e84b06a116063b3cfec9c40620242b94 software@the13thletter.info (Marco Ricci) Tue, 15 Oct 2024 13:16:27 +0200 7d6ac080e84b06a116063b3cfec9c40620242b94 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