Recent commits to derivepassphrase.git (e98174420e001619acfd84a076f9df498076c89c)

Change the code style to use double quotes for strings

2025-08-05T21:11:03+02:00

As is standard in Python auto-formatting (Black, Ruff), we now use
double quotes for strings where possible, reverting to single quotes
only where necessary.

(The numerous code changes in `scripts/`, `src/` and `tests/` stem from
the auto-formatter re-adjusting the quotes.)

Background: I originally started out as a Perl programmer, and in Perl,
single quotes signify literal strings without any interpolation
whatsoever, and double quotes signify strings with interpolation and
escape sequences. In those languages, the choice of string quotes makes
a subtle difference. In Python, the choice of quote character does not
matter, so while there is no reason to prefer one over the other, the
inertia of being used to "single means literal, double means
interpolated" meant that I basically kept my existing style of quoting.

Python, meanwhile, although careful not to *prescribe* one quote
character or the other (see PEP 8), uses double quotes by default in
`str.__repr__` and in docstrings (see PEP 257). The Black
auto-formatter, which Ruff is modeled on, also defaults to double
quotes, arguing in its style guide that (among other things) the empty
string with double quotes unambiguously looks like an empty string,
regardless of fonts and syntax highlighting, but the empty string with
single quotes not necessarily: it may look like a single double quote
character.

More importantly, auto-formatters are specifically designed to make
these (essentially arbitrary) decisions about code formatting for you,
in the name of a uniform code style such that a reader can focus on the
code *content*, not the code *presentation*.  The concrete set of
arbitrary decisions is essentially secondary, but the Black team (and
the Ruff team too) have a pretty good track record of keeping the
resulting code readable and sensibly diffable, and this styling decision
has long been established by Black and "blackened" code "in the wild"
(and thus tested), so I have no reason to object to this particular
arbitrary choice.  Furthermore, there's no need to manually adjust all
quote characters, or even to pay much attention during code authoring to
the quote characters; the auto-formatting pass will take care of
harmonizing them for you.

Given these reasons, continuing to insist on single-quoted strings, in
Python, out of some vague sense of familiarity with *other* programming
languages where quote characters have different meanings, seems rather
untenable to me.
</pre>

Merge topic branch 'ssh-agent-socket-providers' into master

2025-08-04T21:41:47+02:00

* ssh-agent-socket-providers:
  Add a changelog entry for the SSH agent socket provider feature
  Make all command/format/feature enums self-testing
  Document the new level of support for SSH agents (also in `--version` output)
  Update the "SSH key" feature flag in `--version` output
  Support looking up a socket provider, even if merely registered
  Add tests for the SSH agent socket provider machinery
  Introduce a stubbed SSH agent, for testing
  Introduce SSH agent socket providers
  Turn the `ssh_agent` submodule into a subpackage
  Generalize the error message for missing SSH agent support
</pre>

Add a changelog entry for the SSH agent socket provider feature

2025-08-04T21:37:03+02:00

Also include a changelog entry for the self-testing feature flags.
</pre>

Update wishlist to post-v0.5.2

2025-08-03T21:57:58+02:00

</pre>

Release 0.5.2

2025-08-03T21:47:37+02:00

</pre>

Merge topic branch 'fix-version-number' into master

2025-08-03T20:45:36+02:00

* fix-version-number:
  Fix the automatic version increment in `__init__.py`
</pre>

Fix the automatic version increment in `init.py`

2025-08-03T20:45:21+02:00

Despite using software (`bump-my-version`) to automatically update all
version number references throughout the project, I forgot to include
a rule to update the version recorded in the code itself:
`derivepassphrase/__init__.py:__version__`.  Thus, version 0.5 and
version 0.5.1 have been released while both claiming to be version "0.5
alpha 1 (development build 1)".  Oops.
</pre>

Merge topic branch 'pageant-068-080-keys' into master

2025-08-03T20:20:55+02:00

* pageant-068-080-keys:
  Add a script to query test key signatures and derived passphrases from an agent
  Add Pageant 0.68–0.80 signatures and derived passphrases for DSA keys
  Harmonize syntax for the test key definitions
</pre>

Add a script to query test key signatures and derived passphrases from an agent

2025-08-03T20:07:56+02:00

The script attempts to upload each test key to the running SSH agent,
then queries the agent for the signature of the `vault` UUID and
computes the derived passphrase.  If that works, then it prints the test
key, augmented by the new signature and new derived passphrase, in
a `repr`-compatible representation that could principally directly be
included into the `tests` module.

(The real code in the `tests` module basically only differs in
whitespace: the hex codes that make up the signatures and the key data
are wrapped manually, in a manner that highlights their structure but
which is difficult/tedious to produce automatically.)

The script has only been tested on UNIX, and because it imports the
`tests` module directly, it should be run in a compatible environment,
e.g., the `hatch-static-analysis` environment.
</pre>

Add Pageant 0.68–0.80 signatures and derived passphrases for DSA keys

2025-08-03T19:59:19+02:00

I generated these signatures and derived passphrases against a manually
compiled instance of Pageant 0.80.  (Because, as already hinted at in
d2bb555fd898d63b413b37dc2bd1374d82daeffe, it is somewhat hard to obtain
pre-compiled versions of Pageant with a known security hole.  It turned
out to be much easier to compile Pageant ourselves than to find an
unpatched PuTTY distribution.)

(These test vectors are not actually in active use yet.)
</pre>