Repository navigation
fix: start the Noise handshake on a hivemind-core 5.x parameter message - #22
Merged
Merged
Conversation
hivemind-core 5.x sends its step-2 parameter HANDSHAKE with
max_protocol_version, binarize, encodings, ciphers and noise
{patterns, suites}, and no legacy "handshake" flag. HIVEMIND-CRYPTO-1 §3.3
step 2 defines that message by those parameters. The client returned early
unless payload["handshake"] was truthy, so it ignored the message, never
started the Noise handshake and stayed in STATE_HELLO_RECEIVED (2) until
the caller timed out. That is the hivemind-test-harness micropython-e2e
failure "stuck in state 2".
The guard now accepts a shake that carries the legacy flag or a noise
parameter dict. A shake with neither is still ignored.
The README feature line said the key comes from the password through
PBKDF2; that is only the legacy_hub path. It now describes the v3 Noise
handshake with a provisioned PSK.
test/test_core5_shake.py feeds a HELLO and core 5.1.3a1's exact shake
payload to a client with a provisioned PSK: on dev the client stays in
state 2; here it sends Noise message 1 (XXpsk2) and reaches
STATE_HANDSHAKE_SENT. Client suite: 92 passed. With this change and a
provisioned PSK, the harness micropython e2e and embedded tests pass
against a real hivemind-core 5.1.3a1 hub (15 passed).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Against hivemind-core 5.x the client never started the Noise handshake. It waited after HELLO until the caller timed out. This is the hivemind-test-harness
micropython-e2efailure "Client did not reach STATE_READY within 10s (stuck in state 2)".Governing clauses
JarbasHiveMind/architecturedev56f5f9e,hivemind-crypto-1.md.§3:
§3.3, step 2:
The step names no
handshakeflag.The defect
hivemind-core 5.1.3a1 sends this step-2 message, captured from a real hub:
{"max_protocol_version": 3, "binarize": false, "encodings": ["JSON-B64", "JSON-URLSAFE-B64", "JSON-B91", "JSON-Z85B", "JSON-Z85P", "JSON-B32", "JSON-HEX"], "ciphers": ["CHACHA20-POLY1305", "AES-GCM"], "noise": {"patterns": ["XXpsk2"], "suites": ["25519_ChaChaPoly_SHA256", "25519_AESGCM_SHA256"]}}In
_handle_handshake, theSTATE_HELLO_RECEIVEDbranch began withif not payload.get("handshake"): return. That message has nohandshakekey, so the client returned before_should_use_noiseran. It sent nothing, recorded no error, and stayed in state 2. A spy on the live client confirmed this:_should_use_noisewas never called, andlast_errorwasNone.The change
hivemind/client.py: the guard now accepts a shake that carries the legacyhandshakeflag or anoiseparameter dict. A shake with neither is still ignored. What happens next is unchanged: the client uses Noise when it holds a provisioned PSK and a mutual pattern and suite exist, and otherwise it refuses the hub unlesslegacy_hub=True.README.md: the feature line said the key comes from the password through PBKDF2. That is only thelegacy_hubpath. It now describes the v3 Noise handshake with a provisioned PSK and links the existing Protocol v3 section.Evidence
test/test_core5_shake.pyfeeds a HELLO and core 5.1.3a1's exact shake payload to a client with a provisioned PSK.dev1a015betest_a_core5_shake_starts_the_noise_handshakeclient ignored the hub's shake (state 2)XXpsk2) and reachesSTATE_HANDSHAKE_SENTtest_a_shake_without_noise_or_flag_is_still_ignoredClient suite, CPython 3.11: 92 passed.
Against a real hivemind-core 5.1.3a1 hub (hivescope 0.8.5a2), running the harness's
tests/test_micropython_e2e.pyandtests/test_embedded_clients.py:dev, with the PSK provisioned: 4 failed, stuck in state 2;refusing to fall back to the pre-v3 password handshake (HIVEMIND-CRYPTO-1 §3, §5). That refusal is correct.The companion harness PR, JarbasHiveMind/hivemind-test-harness#56, provisions the PSK. The harness job checks out this repo's
dev, so that job turns green once this PR merges.Lint:
hivemind/client.pyhas the same flake8 and ruff findings as ondev, and the new test file is clean.🤖 Generated with Claude Code