3 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	94e11f5e38	update packages	2026-07-31 10:12:05 +02:00
jaap-jan	211eba0666	Keep host key trust in the vault, and make it withdrawable ... A fingerprint approved once is now approved on every machine and survives a restart, because host key trust is a vault item type rather than a dictionary that dies with the process. InMemoryKnownHostStore was what shipped, so the user was asked to verify a fingerprint on every single connection — which is the gap most likely to train somebody to click through the one warning that actually matters. A warning that appears when nothing is wrong teaches that nothing is ever wrong. The fourth item type, and like the third it cost no sync logic: a row, an EF configuration, a migration, a server kind; a secret, a codec, a merge, a cipher, a repository facade and a session property. One row in the client registry. The reconciler, the mirror, the repository, the outbox and the pull filter were not touched. SyncEntityType.KnownHostKey and AadResourceType.KnownHostKey were already reserved, so neither the contract nor docs/crypto.md changed. One item per (host, port, algorithm), because a server legitimately offers several host keys and which one gets negotiated is not ours to predict. Pinning per endpoint would make an algorithm change indistinguishable from an attack. The label is derived rather than stored, which is the one place this type departs from the other three. A user never names a pin — there is nothing to name it after but the three fields it already has — and a stored label is a second copy of data that can disagree with the first after a merge. Relabel returns the secret unchanged, and says why. The store answers the handshake without touching the disk. SshNetConnectionFactory calls FindAsync from inside SSH.NET's synchronous HostKeyReceived event, over .GetAwaiter().GetResult(), which cannot be avoided; doing SQLite I/O plus an AEAD open per lookup there would put the handshake behind the cache. So decryption happens in OpenAsync and RefreshAsync — on unlock and after each sync pass, exactly where the host and key lists already reload — and FindAsync is a dictionary read under a lock with no await inside it. That snapshot is where the one real bug in this change lived. Install originally merged the live pins over the freshly loaded snapshot, to protect a TrustAsync that had landed while the read was in flight. It would also have resurrected every pin the user had just forgotten, and stopped a withdrawal made on another machine from ever taking effect — the store would have healed the deletion back into existence on every refresh. Replacing wholesale and discarding the read instead is correct because writes are the rare case: every write bumps a generation counter, and a refresh whose stamp is stale throws itself away rather than winning. Nothing found this but reading the method again; it is the kind of mistake that passes every test written before it, because the test that catches it is the one the bug tells you to write. Forgetting is new, and persistence is what made it mandatory rather than convenient. A mismatch is a hard refusal with no way to continue — deliberately, and that stays — so pinning a key permanently is also a way to make a legitimately rebuilt server permanently unreachable. Before this change the pin died at exit and the problem solved itself; now it does not. ForgetAsync drops every algorithm for an endpoint, and it is reachable from the host editor rather than from the warning. Putting it on the mismatch banner would have made it two clicks from "this may be an attack" to "connect anyway", which is the affordance the hard refusal exists to deny. The banner already promised the key could be removed in the host's settings; that promise is now true and points at the button. Trust recorded on another machine becomes visible at the next sync pass, not immediately, and that is a decision rather than an oversight. The failure it produces is a first-contact prompt for a host a colleague approved a minute ago: answerable, and self-correcting on the next pass. The opposite trade — polling the vault on the handshake thread to close a one-minute window — buys nothing and costs the property above. The dangerous direction is not reachable at all: a pin recorded here enters the snapshot as part of recording it, so a refresh can never discard a local trust decision. The server learns nothing, and this is the item type where the temptation was real. A plaintext host column would let a known-hosts screen sort and page without decrypting anything, and it would hand the operator the map of every user's estate — assembled, as these things are, out of facts that are each individually harmless. A host row concedes an address only when relay is switched on and the database refuses to store one otherwise (ADR 0004); there is no equivalent excuse here. The table has no column to put one in, and the EF configuration says so where somebody adding it would be standing. Two things about the migration in this commit are worth knowing, because both came out of getting it wrong. It was hand-written first, including its .Designer.cs, and that version is not what is here. Verifying it turned up something that had been quietly assumed: Migration_AppliedCleanly_WithNoPendingModelChanges does not check the model snapshot. It asserts that migrations applied and that none are pending, which a wrong snapshot satisfies perfectly — the snapshot only matters as the diff base for the *next* migrations add, so an incorrect one passes the whole suite and corrupts the following migration instead. The real check is to generate a throwaway migration and confirm its Up and Down come out empty. They did, and the generated designer was byte-identical to the transcribed one across all 1255 lines, so the hand-written work was in fact correct. Then dotnet ef migrations remove --no-build deleted the wrong migration. With --no-build the tool reads the previously compiled assembly rather than the files on disk, and the probe had just changed which migration was last, so it removed AddKnownHostKeyItem and reverted the snapshot. That turned out to leave exactly the right diff base, so the migration here is EF's own output rather than a transcription — a better outcome than the one that was interrupted, arrived at by accident. Never pass --no-build to migrations remove. Mutation tested, all three sabotages detected: dropping the algorithm from KnownHostIdentity.For, merging instead of replacing in Install, and pointing KnownHostKeyCipher at PortForward — which is what a cast from the wire enum's 10 would silently produce. Each is caught both by an assertion about the mechanism and by a behavioural test that never mentions it; the resource-type sabotage is caught by the table from d10a38d and nothing else, which is what that table is for. The end-to-end slice now approves the real sshd's host key through the vault, pushes it, and reads it back on the second simulated machine — including a check that the server learned no address, and that the second machine answers null for an algorithm never offered. 845 tests green. Zero warnings, dotnet format clean. Three things are deliberately not fixed. A tombstone queued over a create that was never pushed is refused by the server as Invalid and parked; that is pre-existing for all four item types, and the fix belongs in VaultItemRepository.DeleteAsync rather than here. Deleting a host, or changing its address, orphans its pins — both are correct as trust decisions, since a pin describes an endpoint and not a bookmark, but nothing surfaces the leftovers. And there is no interface listing pins at all: trust is created at the connect prompt and withdrawn in the host editor. A known-hosts list is where the orphans would become visible, and it wants the vault column rework first, for the same reason the credential editor does.	2026-07-30 11:00:39 +02:00
jaap-jan	49f617b450	Wire the Avalonia shell to the vault ... The host list now comes from the vault instead of from a form. A fresh machine takes a server URL, signs in through the browser, enrolls, and from then on opens with the passphrase alone. DodoSSH.Client.Session is the composition layer: where a profile lives, how it unlocks, and how a machine gets one. ClientPaths picks a non-roaming per-OS directory — %LOCALAPPDATA% and never %APPDATA%, because a SQLite cache that roams between two machines is a corrupt one, and each machine's outbox is its own. SessionOpener needs no transport at all and could not reach one if it wanted to; that is the offline unlock, asserted rather than asserted about. A wrong passphrase, a stale KDF and a grant revoked by a rekey are three different answers, because the remedies are three different things and telling someone to retype a passphrase that was never the problem is worse than saying nothing. The shell's states are the onboarding story. The recovery code gets its own state that cannot be clicked past: it exists for one moment, losing it with the passphrase loses the vault, and there is no server-side reset by design. It is dropped from memory on confirmation rather than merely hidden. Sign-in is a delegate over IVaultServer, so the whole state machine runs in a test against an in-memory server — no browser, no identity provider, no toolkit. The view models are plain observable objects, which is what makes that possible. What it does not cover is whether the XAML binds to the right names; that needs a rendered tree and Avalonia.Headless, and is its own piece of work. Three things found by doing it rather than by reading it: - Pooled SQLite connections keep the database file open after the last context is disposed. On Windows that means locked, so the application could never replace its own cache — and a test could not clean up after itself, which is how it surfaced. Dispose now clears the pool. - EF's SQLite provider puts the database in WAL mode, so the cache is three files. A comment in ClientCacheFactory claimed the opposite; reading PRAGMA journal_mode off a real launch settled it. WAL is the right mode here — a sync pass writes while the interface reads — so the comment was wrong on the merits as well as on the fact. - Enrolling a device key with nowhere to keep the private half would put a wrap on the server nobody can open and make the device list claim this machine can unlock without a passphrase. Device binding is now optional and the shell declines it until the OS keystore is wired. Verified on Windows: the client created %LOCALAPPDATA%\DodoSSH\cache.db and migrated it on first launch, and msedgewebview2 held an established connection to the data plane while the unlock overlay covered it — which is the point of covering the WebView rather than collapsing it, since a NativeWebView that is never laid out is never realised. 630 tests, up from 593. The recovery-code gate and the offline unlock were each verified by breaking them and watching the right test fail. Still to do for M1's actual definition of done: the manual run against the real API and a real Keycloak. Credentials are not a synced entity type yet, so a connection still asks for a password, and the interface says so rather than implying otherwise.	2026-07-29 11:02:19 +02:00