Recent commits to derivepassphrase.git (20bcd8f960b0655700905e9f20f807de15809188)

Work around double-response for "query" extension from ssh-agent (OpenSSH 10.3)

2026-06-13T18:52:55+02:00

Detect and work around `ssh-agent` (OpenSSH 10.3 only) responding twice
when answering a "query" extension request: once with the expected
"extension response" or "success" message, and once with an
unexpected/additional empty "success" message.  We detect the extra
empty "success" message in a generic and protocol compliant way, and
re-align request-response-pair boundaries for any future requests.  From
the agent's perspective, the work-around does a read-only operation and
should not change any permanent agent state, whether there are extra
empty "success" messages or not.

As written, the work-around tests specifically for output from OpenSSH
10.3, but is otherwise agnostic to the "extension response" message
contents and could be easily adapted to trigger for other content
patterns.
</pre>

Split SSHAgentClient.request in two

2026-06-13T16:04:08+02:00

Factor out the serialization of the request message and the
deserialization of the response message from `SSHAgentClient.request`
into separate helper methods.  `SSHAgentClient.request` now only
contains the management of expected response codes, and the raising of
errors if unexpected response codes are received.

While this refactoring was unnecessary so far – requests and responses
were always paired and aligned – the next piece of code I intend to
commit requires handling unpaired responses, and will use only one of
these helper methods.
</pre>

Turn the SSH agent protocol message numbers into ints

2026-06-13T15:56:18+02:00

The `SSH_AGENT` and `SSH_AGENTC` types now inherit from `int`, because
SSH agent protocol message numbers are 8-bit unsigned integers.  This
cuts down on a lot of (previously necessary) type conversion steps
whenever mixed groups of message numbers were involved (e.g. the
`SSHAgentClient.request` `response_code` argument), or when message
numbers needed to be compared with each other (e.g. tests).
</pre>

For SSH agent failures, print the raw response text

2026-06-13T07:52:46+02:00

For SSHAgentFailedError, include the raw response text in the error
message.  (Escaped, but not trimmed.)  The response text is seldom
textual in nature, and discarding non-printable parts of the text turns
out to be much more of a hindrance than a help when debugging unexpected
agent behavior.
</pre>

Merge topic branch 'windows-named-pipes' into master

2026-04-23T19:31:54+02:00

* windows-named-pipes:
  Update the release checklist with PERMITTED_SSH_AGENTS and NON_REENTRANT_SSH_AGENTS
</pre>

Merge topic branch 'documentation-todos' into master

2026-04-06T08:47:01+02:00

* documentation-todos:
  Document the choice between multiple master SSH keys/passphrases or not
  Document how to deal with regular passphrase rotation/rollover
  Document how to deal with "unsupported" special characters in derivepassphrase vault
  Document the tradeoffs between a master passphrase and a master SSH key
  Clean up future documentation ideas
</pre>

Document the choice between multiple master SSH keys/passphrases or not

2026-04-05T22:33:26+02:00

Like the previous three documents, this one too is very preliminary, but
the main points are all present.
</pre>

Document how to deal with regular passphrase rotation/rollover

2026-04-05T21:50:47+02:00

Once more, the quality is "first draft" level, but the main points are
all present.
</pre>

Document how to deal with "unsupported" special characters in derivepassphrase vault

2026-04-05T21:02:18+02:00

Again, somewhat more of a first sketch than finished documentation, but
the main points are present.
</pre>

Document the tradeoffs between a master passphrase and a master SSH key

2026-04-05T19:19:11+02:00

This is still somewhat a preliminary version, but all the main points
are already present.

The FAQ "Should I use one master SSH key, or many keys?" will be moved
to a new, future document.
</pre>