Recent commits to derivepassphrase.git (712a1d0d2abca699aae9bf6473dd336a2f3bd55e)

Rewrite incompatible option checking for more readability

2024-12-19T15:47:42+01:00

</pre>

Document handling of file objects internally in CLI

2024-12-19T15:27:08+01:00

The type hints for `click.open_file` are so broad that our file objects,
intended to be typed as `typing.TextIO`, end up getting typed as
`typing.TextIO | typing.IO[typing.Any]` instead.  Fix this by casting,
explicitly, one level higher.  Also document why no further checks for
readability or writablility are actually performed.
</pre>

Fix hypothesis settings for uninstrumented runs

2024-12-19T15:18:58+01:00

The state machine tests appear to have such slow data generation that
they trigger `hypothesis` health check errors even in uninstrumented
runs (i.e. without a trace function running).
</pre>

Hoist and add tests for internal `key_to_phrase` CLI function

2024-12-19T15:04:11+01:00

Commit d15069d2db4040d444f65d7c3db6a854f4adcb92 extended the internal
`key_to_phrase` CLI function, adding more expansive error handling and
better error messages.  The new error handling still needed to be tested,
however.  When actually writing tests for this function, it turns out to
be cumbersome to trigger the various scenarios directly, because, as an
internal function, this means issuing a full CLI call in a high-level
mock environment.  Instead, we now hoist the function to the outer level,
making it easily accessible to tests and easier to isolate and prepare
a smaller and more specialized mock environment for.

(The primary reason this function was internal before was its use of the
`err` error callback, which still is internal to the CLI, but will now
be supplied explicitly as a callback.)
</pre>

Retire `allow_derivepassphrase_extensions` argument to `validate_vault_config`

2024-12-19T15:04:11+01:00

As the Unicode normalization form is now set via the central
configuration file instead of the `vault` data file, there are currently
no defined `derivepassphrase` extensions to the vault configuration file
schema.  Given the new central configuration file and the commitment to
preserve compatibility of the `vault` configuration import/export, we do
not anticipate any future `derivepassphrase` extensions to the schema.
Thus, retire the `allow_derivepassphrase_extensions` validation option.

Also adapt all tests and test datasets accordingly.
</pre>

Add changelog entry for the introduction of the central configuration file

2024-12-19T15:04:11+01:00

</pre>

Turn Unicode normalization preferences into user configuration settings

2024-12-19T15:04:11+01:00

Instead of storing Unicode normalization preferences in the vault
configuration file, store these settings in the user configuration file:

  * For a service `SERVICE`, consult the configuration key
    `vault.SERVICE.unicode-normalization-form`.
  * If that is unset, or if there is no service, use
    `vault.default-unicode-normalization-form`.
  * If that too is unset, default to `NFC`.
</pre>

Introduce a central user configuration file (and division of responsibility)

2024-12-19T15:04:11+01:00

Introduce a new file for centralized user configuration of
`derivepassphrase`, which we expect the user to write and maintain, and
which we will never attempt to write to.  Treat the existing "vault"
configuration file as a "data" file, which is `derivepassphrase`'s
responsibility to write and to maintain, and which the user shouldn't
edit directly.

In general, we now divide the configuration file set semantically into
"user" files and "data" files with the aforementioned responsibilities:
"user" files are managed by the user, "data" files are managed by the
application.  (This mirrors the distinction in the XDG Base Directory
Specification, although we do not use their paths or their environment
variables.)  We choose TOML as the file format for "user" files, because
it is the simplest configuration file format with both a robust parser
in the Python standard library and support for comments.  The "data"
files currently use JSON, but may use other serialization formats in the
future as well.

We envision some use cases for the user configuration file such as
disabling certain expected warnings, or declaring the desired Unicode
normalization form of a text string, but as of now, no such
configuration is defined or supported.
</pre>

Highlight security warnings and risks more prominently in the docs

2024-12-19T15:04:11+01:00

</pre>

Make obtaining the compatibility config filename more explicit

2024-12-19T15:04:11+01:00

When obtaining the compatibility config filename `settings.json` from
`cli._config_filename`, rename the corresponding subsystem from
`settings` to `old settings.json`.  Furthermore, pass that explicit
subsystem upon each call.  This frees us up to change the default
subsystem in a future commit.

Because this is not a public function, this is not a change in the
public API.

Some reformatting is necessary.
</pre>