https://git.schokokeks.org/derivepassphrase.git/tree/23abeb72fb91e2ead0bb029138fd68d0fdf23e9c 2024-10-16T00:29:21+02:00 tag:gitlist.org,2012:commit/23abeb72fb91e2ead0bb029138fd68d0fdf23e9c 2024-10-16T00:29:21+02:00 Marco Ricci software@the13thletter.info <pre>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. &lt;/pre&gt; tag:gitlist.org,2012:commit/71c3866eef5deae63ad66f0100c5bf294917a749 2024-10-15T13:46:21+02:00 Marco Ricci software@the13thletter.info <pre>&lt;/pre&gt; tag:gitlist.org,2012:commit/7d6ac080e84b06a116063b3cfec9c40620242b94 2024-10-15T13:16:27+02:00 Marco Ricci software@the13thletter.info <pre>* 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. &lt;/pre&gt; tag:gitlist.org,2012:commit/e6710afcce476a8b4301ce49846b44fd6cf714f2 2024-10-15T13:15:38+02:00 Marco Ricci software@the13thletter.info <pre>&lt;/pre&gt; tag:gitlist.org,2012:commit/16068a30b5fbbeb0b8624c52ac664911b24b83f4 2024-10-15T13:07:09+02:00 Marco Ricci software@the13thletter.info <pre>&lt;/pre&gt; tag:gitlist.org,2012:commit/c1bf00eadd1bf733ac25a25eafbe110d61936c54 2024-10-15T12:47:49+02:00 Marco Ricci software@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. &lt;/pre&gt; tag:gitlist.org,2012:commit/eb2e29c26a1baf9c59d6ed5dfa787b9902e5bb4f 2024-10-15T11:22:02+02:00 Marco Ricci software@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. &lt;/pre&gt; tag:gitlist.org,2012:commit/23177a3206f5c0b4220d8ee496f887ed7e8cb0ab 2024-10-14T23:14:09+02:00 Marco Ricci software@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. &lt;/pre&gt; tag:gitlist.org,2012:commit/c9faa4d734f4d6edf148e6284e51e9e48826cc35 2024-10-14T23:11:27+02:00 Marco Ricci software@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.) &lt;/pre&gt; tag:gitlist.org,2012:commit/9713343438217b44f3eb408b54f0d17f8baca64a 2024-10-14T22:31:40+02:00 Marco Ricci software@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). &lt;/pre&gt;