Recent commits to derivepassphrase.git (6a7423c92f8bda8e46e632f282bce18d4be673d7)

Reformat "vault" tests

2025-01-27T19:46:57+01:00

Reformat the "vault" tests.  This includes retiring the `Vault` type
alias and using the proper Google-style `vault.Vault` instead, because
the API documentation does not correctly resolve this type alias
otherwise.
</pre>

Document the vault "interchangable passphrases" artefact as an FAQ

2025-01-27T19:39:03+01:00

</pre>

Detect (and test for) pairs of interchangable vault passphrases

2025-01-27T15:36:38+01:00

The "vault" derivation scheme internally uses PBKDF2-HMAC-SHA1 to
generate a pool of random bits from which the derived passphrase is
constructed.  Here, the master passphrase is passed directly to
HMAC-SHA1 as the key; see [RFC 2898][].  By construction, HMAC-SHA1
requires keys to be exactly 64 bytes long (the internal block size of
SHA1), so keys larger or smaller than 64 bytes are mapped to equivalent
64-byte keys.  This keyspace reduction means that master passphrases
under vault are not unique, and since the mapping is simple enough,
"master passphrase collisions" have actually been observed during
hypothesis testing.

Therefore, we implement a new interface to query whether two master
passphrases are interchangable under vault.  We also test expected
interchangability and non-interchangability of master passphrases
explicitly with hypothesis-based tests, both for mixed passphrase
categories (larger than, smaller than, or exactly 64 bytes) and for each
category separately.

[RFC 2898]: https://datatracker.ietf.org/doc/html/rfc2898  "See Section 5.2 and Appendix B.1.1."
</pre>

Add hypothesis-based test for service name dependence of derived passphrases

2025-01-27T15:23:35+01:00

As part of a larger quality assurance effort, explicitly test that
derived passphrases depend on the service name.

The obvious counterpart, that derived passphrases depend on the master
passphrase, it not quite so straightforward, and will be tackled in
a later commit.
</pre>

Add hypothesis-based service name type tests for the "vault" module

2025-01-27T00:35:36+01:00

Check that equivalent service name strings, byte strings and byte arrays
all derive the same passphrases.
</pre>

Signal failed assumptions instead of passing tests in the "vault" module

2025-01-26T23:42:36+01:00

One hypothesis-enabled test function of the "vault" module tests that
the constructor accepts a given set of settings.  While the generator
attempts to yield only satisfiable settings, there are certain settings
that cannot derive a passphrase for one service name, but can derive one
for other names.  In these cases, the specific generated characters and
occurrence limitations together disallow all otherwise eligible
candidates for the next character.

Tests with such configurations should actually be skipped, but
hypothesis-based tests need different skip handling than normal
pytest-based tests.  Previously we would "fake" skipping by silently
returning early, which suggests that the test actually *passed*.  Now,
we use `hypothesis.assume` to signal to hypothesis to generate
a different datum instead.
</pre>

Document hypothesis examples for "vault" tests the proper way

2025-01-26T23:40:15+01:00

Use `hypothesis.example(...).via(...)` instead of source code comments.
</pre>

Rearrange hypothesis tests in the `vault` module

2025-01-26T20:10:35+01:00

Just like in 9db6c6591de054433ae98d59f7930364e7d03286 for the
`ssh_agent` tests, arrange the `vault` hypothesis tests so that they lie
next to the respective non-hypothesis test, if any.  Also rename and/or
renumber them as necessary.
</pre>

Rearrange hypothesis tests in the `ssh_agent` module

2025-01-26T16:34:47+01:00

Arrange the hypothesis tests so that they lie next to the respective
non-hypothesis test, if any, instead of bundling them all in the same
testing class.  By doing this, related tests are closer to each other,
if possible.  Use the hypothesis mark instead of the testing class if
filtering is required.

Additionally, since the helper functions `as_ssh_string`,
`canonicalize1` and `canonicalize2` now are visible in and assigned to
a broader context, give them proper docstrings.
</pre>

Add more hypothesis tests for the `ssh_agent` module

2025-01-26T16:21:45+01:00

Add more hypothesis tests for SSH string encoding and decoding, based on
David R. MacIver's articles.  Also document the explicit examples in the
proper way.
</pre>