Recent commits to derivepassphrase.git (63053f40ef9487c6ede43eb863bbd9abe578e258)

Add changelog entry for key/phrase and falsy behavior changes

2024-10-08T10:04:11+02:00

Document the changes in 7d2f2b1bda31ead428d3c009772aaf3d2261d60c and
798ddc103c6c03835394733aeca128b970aacd06 in the changelog.
</pre>

Align behavior with vault concerning falsy values in config

2024-10-08T09:32:00+02:00

The original vault(1) sometimes checks only for falsy values (in the
JavaScript sense) for its configuration settings.  `derivepassphrase`
however uses strict type and value checks, and rejects falsy values of
the wrong type.  This behavior is a visible deviation from vault(1), and
shall thus be removed.

A new function, `_types.clean_up_falsy_vault_config_values`, normalizes
falsy values in a vault configuration to their correct types, in-place.
Running this on a potential vault configuration and then calling
`_types.is_vault_config` should return the same validity results as
vault(1) does.

The new handling of falsy values invalidates most of the tests for
validation errors, as `None`/`null` was a common way to generate an
invalid setting.  Instead, keep a master list of vault configurations
that is used (perhaps filtered first) for all validation tests, and test
the handling of falsy values by generating vault configurations with
falsy value replacements from the master list (a custom `hypothesis`
strategy).

On that note, the existing `_types.validate_vault_config` has proved
rather difficult to keep at 100% coverage with the new example vault
configurations, because some of the error conditions are triggered
elsewhere.  Accordingly, instead of treating global and service-specific
settings separately and quasi-duplicating all validation checks, unify
them into a queue of settings dicts to check, only mildly adjusting for
the very few differing keys between them.

GitHub: Closes #17.
</pre>

Align behavior with vault concerning key and phrase in config

2024-10-05T23:30:07+02:00

When both a key and a passphrase are specified in the vault
configuration, vault(1) would unconditionally use the key, *unless* the
command-line overrides this choice.  `derivepassphrase` however always
gave preference to the most "specific" configuration, and would error
out if both key and passphrase were specified at the same specificity.
While arguably more intuitive, this behavior is a visible deviation from
vault(1), and shall thus be removed.

Besides two instances of the `test_200_is_vault_config` in
`tests.test_derivepassphrase_types`, this also flips the result of
`test_205_service_phrase_if_key_in_global_config` in
`tests.test_derivepassphrase_cli`.  Because that flipped version needs
extra mocking infrastructure – the `sign` function – and because that
mock function already exists in another test (but local to that test),
promote that mock function to global and shift it into the top-level
`tests` module.

Since we had to update the imports in `tests` anyway, we also purged
`dpp.vault...` references in `tests.test_derivepassphrase_cli` in favor
of `vault...`.
</pre>

Tell MkDocs to ignore scriv's changelog snippets

2024-10-04T10:55:32+02:00

The master changelog file is included, of course, but we don't want
MkDocs to bother with the single snippets (rendering them, generating
warnings that they're not part of the navigation tree, etc.).
</pre>

Update required Python version in the README

2024-10-03T13:40:52+02:00

This was forgotten while adding Python 3.9 support.
</pre>

Relax hypothesis deadline for another slow-ish test

2024-10-03T13:30:36+02:00

The vault settings validation test keeps timing out on my older
hardware, when running without the C tracer and at moderate power saving
settings.  I can only presume it would time out similarly on even
lower-powered hardware, such as a Raspberry Pi.
</pre>

Merge topic branch 'issue15-graceful-af_unix-degredation' into master

2024-10-02T20:35:24+02:00

* t/issue15-graceful-af_unix-degredation:
  Fail gracefully if UNIX domain socket support is unavailable

GitHub: Closes #15.
</pre>

Fail gracefully if UNIX domain socket support is unavailable

2024-10-02T19:26:30+02:00

To talk to the SSH agent, we currently require UNIX domain socket
support, but not every Python on every system supports this (notably:
Windows).  If we detect such missing support, fail gracefully and with
a useful error message, instead of a technical reason such as
`AttributeError`.

Besides the new failure modes that API consumers will need to handle,
this results in one more observable change: socket objects passed to the
`SSHAgentClient` constructor are now required to be already connected.
The constructor will no longer prepare sockets it didn't create itself
in any way.

This new failure behavior also has consequences for the tests, which so
far have naively assumed UNIX semantics and UNIX domain socket support.
So change the testing machinery to automatically skip any test that
involves constructing a custom SSH agent client *and* expecting that
step to go well.  Furthermore, since the "no support" constellation can
be reasonably well simulated even on systems that *do* have UNIX domain
socket support (via pytest's monkeypatching fixture), include explicit
tests on the API and the CLI level for the "no support" constellation,
in any case.
</pre>

Merge topic branch 'support-py39' into master

2024-10-02T09:32:06+02:00

* t/support-py39:
  Add changelog entry for Python 3.9 support
  Add support for Python 3.9
  Accomodate known slow tests in hypothesis deadline
  Fix awkward parametrization declaration for SSH agent client tests
</pre>

Add changelog entry for Python 3.9 support

2024-10-02T09:31:40+02:00

</pre>