From 7c46b4e7dc2893974a37d6a701123a95803fcb95 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Tue, 18 Aug 2026 11:00:32 +0200 Subject: feat(client): hybrid sign-in — passphrase once, then this device's key MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit D4. The passphrase stays the account's credential and its only recovery path; what changes is that it is not asked for on every launch. **The renderer never holds the device key.** It is generated, stored and used entirely in the main process, which signs `meshbay:user_auth::` on request. Same rule as the save dialog, for the same reason: the renderer is the part of this application that parses decrypted content from nodes, which is attacker-controlled input. And this key is *not* a per-node identity key — those are generated per node and never leave that relationship, so nothing here correlates a person across operators. First run asks which hub, with no default. A client that picks its own hub is a client that can be pointed at one, and the address is the whole of what this application trusts a hub for — the interface comes from the package. Verified against a hub running this code, not against the deployed one: register 201 → passphrase login 200 → device register 201 → **device sign-in 200 with a real session** → `/v1/users/me` 200 → a stranger's key 401. The signature was also checked directly against the hub's own Python verifier before any of that. Inside the running application, over the debugging protocol: the bridge reaches the main process, the renderer calls the hub **through it** (200 — the CORS fix working end to end), and a call to a host that is not the configured hub is refused. **Not verified:** safeStorage persisting the key. This session has no secret service, and standing one up in xvfb did not succeed. The application behaves correctly there — it *refuses* rather than storing unprotected, and now says so in Settings, which is a real case rather than a hypothetical one since it is exactly what a headless or minimal desktop looks like. Worth remembering for next time: meshbay.org runs whatever was last deployed. It answered 405 on the Stage-C endpoints and reported MNP 0.2 while the tree had 0.3, so a local `uvicorn meshbay_hub.app:create_app --factory` on SQLite is what tests hub changes. Nothing was deployed to production for this. 799 tests pass; e2e.py passes end to end. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index 880756e..61d8e96 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -369,6 +369,19 @@ anything that assumes one key per person. directives, not text — the same mistake as reading a CSP out of the comment above the meta tag +- **The device's hub key lives in the main process, never in the renderer.** + Generated, stored and used there; the interface asks for a signature over + `meshbay:user_auth::` and is never handed a key. Same rule as + the save dialog, for the same reason: the renderer parses decrypted content + from nodes, which is attacker-controlled input. It is **not** a per-node + identity key — nothing here correlates a person across operators + +- **A local hub is the way to test hub changes.** `uvicorn meshbay_hub.app:create_app + --factory` with a SQLite URL and a throwaway key runs the current code on + loopback in seconds. meshbay.org runs whatever was last deployed — it reported + MNP 0.2 and 405 on the Stage-C endpoints while the tree had 0.3 — so testing + against it proves what is deployed, not what is written + ## Two lessons that cost four rounds of live testing - **`QE/deploy/e2e.py` cannot test `app.js`.** It is a second implementation of the -- cgit v1.2.3