https://git.schokokeks.org/derivepassphrase.git/tree/855a758e4f21ce51fec6978b575caece90dd515f Recent commits feed provided by GitList. * t/usage-fixes: Fix user interface errors if the SSH agent does not work Fix usage of `--debug`, `--verbose` and `--quiet` options https://git.schokokeks.org/derivepassphrase.git/commit/855a758e4f21ce51fec6978b575caece90dd515f software@the13thletter.info (Marco Ricci) Tue, 17 Dec 2024 20:13:49 +0100 855a758e4f21ce51fec6978b575caece90dd515f While the configuration and interactive selection of an SSH key is properly guarded against (i.e., any exceptions are wrapped into proper command-line error messages), the calls to `vault.Vault.phrase_from_key` were not similarly guarded. This has now been fixed. The fix also uncovered an incorrectly specified mock function in the test suite, which has been repaired as well. https://git.schokokeks.org/derivepassphrase.git/commit/d15069d2db4040d444f65d7c3db6a854f4adcb92 software@the13thletter.info (Marco Ricci) Fri, 13 Dec 2024 14:52:17 +0100 d15069d2db4040d444f65d7c3db6a854f4adcb92 The three "verbosity" options `--debug`, `--verbose` and `--quiet` set the logging level for `derivepassphrase`, globally. Because `click` does not support mutually exclusive options by default, these options are implemented as boolean flags, and it is possible to override earlier verbosity settings with later options. The previous setup treated the three options as disjointed flags, so each callback was called once, irrespective of the others, so the aforementioned intended overriding behavior was not working properly. In addition, the callback was faulty, always enabling each of the flags. The new setup now links all three options to the same flag, with different flag values. We further expose the option objects at the top level, and unify the three callback functions to a single one. As a side effect, we also fix a misclassified diagnostic during configuration file migration ("vault" derivation scheme). https://git.schokokeks.org/derivepassphrase.git/commit/58f6653d0d7a886d1cf02f70bb005de640a6b0b0 software@the13thletter.info (Marco Ricci) Fri, 13 Dec 2024 14:25:44 +0100 58f6653d0d7a886d1cf02f70bb005de640a6b0b0 * t/hypothesis-fixes: Actually correctly implement custom hypothesis settings Overhaul the state machine for testing vault configuration imports https://git.schokokeks.org/derivepassphrase.git/commit/a6a657011d5d39671bd4d0b8bbaa10617e32cfb9 software@the13thletter.info (Marco Ricci) Thu, 12 Dec 2024 12:03:53 +0100 a6a657011d5d39671bd4d0b8bbaa10617e32cfb9 The `hypothesis.settings` decorators are intended to modify the currently active `hypothesis` settings profile for singular tests. However, the profiles are defined and selected only *after* the `tests` module has been loaded, so any settings defined in the `tests` module actually modify the `hypothesis` default settings, not the selected profile's settings. Fix this by defining decorators that construct and apply the correct settings, which defines the settings objects deferredly, instead of defining them immediately. https://git.schokokeks.org/derivepassphrase.git/commit/7189e0e3b7eb053181c6a28cc585c7c4aebb6ee7 software@the13thletter.info (Marco Ricci) Thu, 12 Dec 2024 12:03:30 +0100 7189e0e3b7eb053181c6a28cc585c7c4aebb6ee7 Redesign the state machine for testing vault configuration imports, and the `hypothesis` generation strategies for vault configurations, to overcome the following problems with the old design: 1. Data generation of vault configurations needs many redraws, because we express dependencies by rejecting the whole tuple of properties if it doesn't match. We could instead draw the independent properties, and conditional on their values, draw the dependent ones; cf. Gibbs sampling vs. rejection sampling. 2. `hypothesis` implements state machine rule selection as drawing from a list of eligible rules. This list must remain static during redrawing and backtracking, lest `hypothesis` complains the test is flaky. While it isn't expressly forbidden to store state manually in the state machine, the old design made the list of eligible rules dependent on the implicit machine state and on the generated values, in a way that led to flakiness. Fix these issues by doing the following: - Rename the class from `ConfigMergingStateMachine` to `ConfigManagementStateMachine`, because it's no longer just about merging configurations. - Implement strategies to build a full vault configuration from multiple full settings configurations, and a partial settings configuration from a full settings configuration. Draw interactively, first the independent properties, then the dependent ones. This tackles issue (1). - Overhaul the state machine, effectively rewriting it from scratch, by managing all state in `hypothesis` bundles. Ensure the bundles are filled at initialization, and that each (non-bookkeeping) rule begins with storing the configuration and ends with checking and returning the transformed configuration. Filter the values drawn from the bundles, instead of filtering the rule set based on the machine's current state. This tackles issue (2) above. The resulting state machine should have an acceptable drawing success rate (without needing to override the `filter_too_much` `hypothesis` health check), at the cost of slow(ish) drawing speed and slow(er) execution speed because the configuration must be replayed onto disk during each step. On the other hand, the single steps now are more repeatable and more independent of each other. This implementation makes use of several top-level functions and constants, outside of the state machine class. Attempting to use static and class methods instead leads to messy workarounds because of the name resolution rules and because of mismatches in the calling conventions of static and class methods during class definition vs. during execution time. In the end, the "top-level functions and constants" version is the most straight-forward to read. https://git.schokokeks.org/derivepassphrase.git/commit/6755c20096ad41e99aceede4a9a4c914520a5d6f software@the13thletter.info (Marco Ricci) Thu, 12 Dec 2024 12:03:30 +0100 6755c20096ad41e99aceede4a9a4c914520a5d6f * t/import-override-mode: Allow the user to overwrite the current vault configuration Test config merging with partial service configs too https://git.schokokeks.org/derivepassphrase.git/commit/d505bce64d4b2251c87b59f1577a072e8ed551b4 software@the13thletter.info (Marco Ricci) Thu, 12 Dec 2024 12:02:50 +0100 d505bce64d4b2251c87b59f1577a072e8ed551b4 In the "vault" derivation scheme, commands that edit or import a configuration actually merge with the existing configuration, for compatibility with the original vault(1). However, sometimes it is desired to replace the existing configuration instead, when importing or when setting a (service or global) configuration. We introduce a new `--overwrite-existing` command-line option that signals exactly that, and a `--merge-existing` option which signals the (previously implicit) default merging behavior. https://git.schokokeks.org/derivepassphrase.git/commit/9a88450ed3941eae25938053149a8bbf89c319c8 software@the13thletter.info (Marco Ricci) Thu, 12 Dec 2024 11:59:47 +0100 9a88450ed3941eae25938053149a8bbf89c319c8 Using larger numbers of settings (and services) leads to a very low probability of actually finding a viable path of action in the state machine; the run is a no-op, save for the initial setup. Presumably, we need a larger pool of readily-assembled and/or more cross-compatible objects, instead of the stepwise approach employed here with service names, settings, and configurations. This needs to be addressed in a future commit, however. https://git.schokokeks.org/derivepassphrase.git/commit/7a4f215faf88345111135676203f9e7373e2ea98 software@the13thletter.info (Marco Ricci) Thu, 12 Dec 2024 11:59:47 +0100 7a4f215faf88345111135676203f9e7373e2ea98 * t/pageant082: Explicitly support Pageant 0.82 in the test suite GitHub: Closes #14. https://git.schokokeks.org/derivepassphrase.git/commit/e97b966ecba87289b839e0fbac736f0b53782ed5 software@the13thletter.info (Marco Ricci) Mon, 09 Dec 2024 11:36:00 +0100 e97b966ecba87289b839e0fbac736f0b53782ed5