2 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	1faea42b94	Unlock with this machine's device key, without a passphrase or a network ... The second of ADR 0007's three pieces: the seam a keystore plugs into, the wrap cached where an offline unlock can reach it, and the unlock path itself. What is still missing is the keystore — UnavailableDeviceKeyStore is what the application composes for now, so behaviour is unchanged until piece three lands. IDeviceKeyStore holds exactly 32 bytes, and only because the cache key moved first. It would have had to hold the local cache key alongside the X25519 scalar — a second live secret at rest, going stale on every passphrase change — had 7016ce3 not re-keyed that to the identity bundle. ADeviceUnlock_ReadsTheSameCache ThePassphraseWrote is the test that ties the two commits together: under the old derivation this session would have opened the identity and then found its own cache unreadable. The wrap is cached at registration rather than fetched at unlock, which is the whole point. The one unlock path that exists to save the user typing must not be the one that only works online; a laptop on a plane is precisely where a gesture should help. Every way this fails returns a status rather than throwing, because none of them are exceptional — a cancelled fingerprint prompt is the most ordinary thing in this file. Three statuses rather than one, because the caller says a different sentence for each: no device registered (the normal state of a machine nobody opted in on), the machine would not release the key (declined gesture, or a Hello key invalidated by a PIN reset — deliberately indistinguishable, since the remedy does not differ), and the key was released and did not open the wrap (a rotated identity, which will never succeed again and needs re-registering). A keystore returning the wrong number of bytes lands in the third rather than crashing the unlock screen. The subtle defect this could have shipped is in UnlockStore.Apply. That method runs on every sign-in from a /me response, which knows nothing about this machine's keystore — so assigning the device columns unconditionally would delete the wrap on the next launch, and the user's fingerprint would stop working for no visible reason and no error anywhere. The columns are therefore written only when the incoming material carries them, with AttachDeviceAsync and DetachDeviceAsync as the only paths that set them deliberately. Mutation tested: removing the guard fails RefreshingTheProfile_DoesNotDiscardTheDeviceWrap and nothing else. RegisterDeviceAsync lives on VaultSession because sealing the bundle is the one step only an open session can do, and the session is the bundle's custodian. Everything else arrives as a parameter, exactly as SyncAsync takes its transport, so the session still knows nothing about how either the wire or the keystore is implemented. Its steps are ordered so a failure cannot leave a lie behind: the key is generated, saved locally, and only then registered with the server. A server row whose private half was never stored is a device that can never unlock and that the account claims can — worse than not offering the feature at all — so the write that could produce it happens after the one that prevents it. ForgetDeviceAsync is deliberately half a job, and says so. It stops this machine unlocking without a passphrase, which is what a user turning the feature off means, but the server's wrap row survives and the account will go on listing a device that cannot unlock. Deleting it needs an endpoint that does not exist yet. Half with the gap recorded beats a method whose name promises the other half. The client cache gained two nullable columns and a migration, generated rather than hand-written this time. 876 tests green, 10 of them new. Zero warnings, dotnet format clean. Remaining: the Windows Hello store and the unlock-screen UI. That is where the Windows target framework lands, and where automated testing stops — a gesture needs hardware and a person, so the last piece is the one that has to be looked at rather than asserted.	2026-07-30 13:37:35 +02:00
jaap-jan	8d2416a602	Add the encrypted local cache and the sync client ... Three new client projects, and the wire-contract fix they needed. DodoSSH.Client.Domain holds the decrypted item model and the three-way merge, with no I/O at all — so the suite that decides whether a credential can be lost runs in milliseconds with nothing to mock. Scalars defer to the server on a genuine clash so every replica resolves the same triple identically and two clients cannot ping-pong; directives merge per name so two people each adding one both keep theirs; the jump chain merges as a whole value because its order is the route. Whatever loses is returned rather than dropped. DodoSSH.Client.Storage is EF Core on SQLite, no SQLCipher: the rows are already ciphertext, so an encrypted file would protect protected bytes at the cost of a native dependency. It keeps the server's state and the outbox in separate tables, which is what preserves the common ancestor a merge needs. One pending operation per item, enforced by a unique index. DodoSSH.Client.Sync is the pull/apply/push loop. Pulling never decrypts — a change with no local work pending is plumbed as ciphertext — so a first sync of thousands of items does not run twice as many AEAD operations for nothing. Contracts: EncryptedPayload gains WrappedDataKey and DataKeyId. The specification has required a per-item data key since crypto.md §3, the columns have existed since the first migration and DshAad.ItemPayload binds the id, but this record had nowhere to put either — so a spec-compliant item could not be transmitted at all. Found by writing the client that has to produce one. Also closes a hole in AadResourceType, which had no value for the HostTag and HostCredential that SyncEntityType has always listed. Four bugs the tests found, not review: - SQLite refuses to order or compare its own DateTimeOffset mapping, and throws at execution rather than model build. Collecting tombstones and listing conflicts are both that shape, so this was a crash waiting for the first user with a deleted host. Timestamps are integers now, by convention so a later field cannot be the one left unconverted. - SQLitePCLRaw 2.1.11, which EF resolves, is covered by GHSA-2m69-gcr7-jv3q. Pinned forward as a family. - Resurrecting content from a remote deletion cleared the original before queueing the copy. Two transactions, so a crash between them lost the work; reversed, and the rescued id is derived from the tombstone so a replay coalesces instead of duplicating. - Several equality assertions went through Shouldly's ShouldBe, which compares IEnumerable element-wise and so tested nothing about the Equals these types exist to provide. Corrected; the falsification that caught it went from 2 failures to 6. The push response's cursor is deliberately ignored. It sits after this client's own writes, so adopting it skips anything another client committed at a lower sequence in the window between a pull and a push — permanently. Re-reading one's own writes is idempotent and costs a page. The Contracts doc that invited the shortcut now says so. 593 tests, up from 448. The delete-versus-edit rules, the ancestor retention, the fresh operation id on coalesce and the cursor safeguard were each verified by breaking them and watching the right test fail.	2026-07-29 10:27:37 +02:00