21 Commits

Include renames

Author	SHA1	Message	Date
jaap-janandClaude Opus 5	a43286ece8	Let a team change hands, and be joined by somebody with no account yet ... M3 built teams and stopped short of the two operations that decide who controls one. Both were written down as refusals rather than omissions: ADR 0009 listed ownership transfer under "deliberately not built", and design-import-gaps said an invitation needed "a token with a lifetime and an outbound mail path". One of those reasons had expired and the other never applied — an invitation does not need a token if it is not a thing anybody presents. Handing a team over is one write. The member you name becomes owner and you become an admin, in a single transaction, because ownership is sole: promoting first leaves the team owned twice, demoting first leaves it owned by nobody, and there is nobody left with the authority to finish a transfer that stopped in the middle. That is also why it is not two calls to the role endpoint, which refuses Owner outright. The outgoing owner is demoted rather than removed — removing them would revoke their vault key grants and flag every team vault for rekey, which is a far larger act than the one asked for, and somebody handing over a team is usually staying in it. It unblocks the thing that was impossible before: an owner can now leave, by handing the team on first. An invitation is a standing instruction rather than a message. This server has no outbound mail path, so nothing is sent and there is nothing for the invitee to present. The row says the next account signing in with that address joins this team at this role, and telling them to sign in is the caller's job over a channel this server does not carry. A link nobody can deliver would be worse than none. It lives in its own table rather than becoming a membership with MembershipStatus.Invited, and that member stays unwritten for the reason it always was: team_membership.user_id is not nullable and carries a foreign key, so somebody who has never signed in has nothing for that row to point at. Widening it would make the unique index on (team, user) meaningless, because PostgreSQL counts every NULL as distinct. Verification is the security boundary, and nothing in this server read it before. A claim requires the access token to assert email_verified. An invitation decides what the server will serve, so one claimable by anybody able to obtain a token carrying somebody else's address is a way into a team — which is precisely the attack OidcOptions.AllowEmailLinking exists to refuse, and it would have been reintroduced by the back door. There is deliberately no setting that relaxes it: a flag that exists is one somebody turns on for the afternoon their provider is misconfigured. Absence is refused rather than trusted, and logged, because a provider that never sends the claim otherwise leaves every invitation pending with nothing anywhere saying why. Claiming happens at just-in-time provisioning and again on an hourly sweep. The sweep is what makes it recoverable rather than one-shot — an invitation issued between an account being created and that person next signing in would otherwise be stranded for ever — and it shares its rate with the last-seen write because both are housekeeping nobody is waiting on. Archiving is refused while a team owns a vault, and that refusal is the end of the road rather than a step on it. A team vault is readable because of membership, so archiving one that still owned vaults would take them away from everybody holding a key, including the caller, quietly and all at once. Nothing in this product deletes a vault, so no order of operations gets past it today — which is stated with a count of what is in the way, for the reason the SFTP layer refuses a recursive delete: a refusal is visible and a quiet removal is not. It is owner-only, as handing over is; renaming is not, because a rename is visible to everybody and reversible by anybody who can do it. The slug is not renameable at all: it is unique only among live teams, so a rename could take one an archived team is still holding, and that team could then never be restored. LAST ACTIVE is real and coarse on purpose. UserAccount.LastSeenAtUtc is refreshed on ordinary authenticated requests, at most once per account per hour, through ExecuteUpdateAsync — user_account carries the xmin concurrency token, so a read-then-write on the hot path would start losing races between one user's own overlapping requests. An hour is the granularity the question is actually asked at, and the interface draws it to the day rather than the minute so it does not read as a precision that is not there. The remarks in Contracts and in the view model that argued at length for the column's absence are rewritten rather than extended; both had become false. Two endpoints already existed and nothing called them. ChangeTeamMemberRole and ListVaultGrants have been reachable since M3. The role picker refuses Owner itself rather than letting the server do it, since the interface already knew the rule; the key-holder list sits under the vault rather than beside the member, because a grant is per vault and a count on a member row would imply per-item sharing, which is M5. It lists withdrawn and stale grants and says which they are — a list that dropped them would show a departed colleague as merely absent rather than as somebody whose key was taken away — and staleness is decided by comparing generations, since a grant can be Active and still open nothing. ADD MEMBER stopped being a dead end. An address the directory did not know used to end at a sentence telling the user their colleague had to sign in first. It invites them instead, from the same button, because which of the two applies is a fact about the server's account table rather than about what the user is doing; which one happened is reported afterwards, because that decides what they do next. An address that merely has an account is invited rather than refused: refusing would have made the endpoint an oracle for which addresses have accounts here, answerable by anybody willing to create a team first. The phone has a TEAMS screen, behind MORE, and it is the reverse of every other row in design-import-gaps: a shipped screen the design had no slot for. It is there because an invitation is claimed by signing in, so somebody told they are now in a team is at least as likely to be holding a phone — and a membership visible only on a head they never installed is one they cannot see. It draws SHARE KEY and nothing that takes something away: wrapping a key is the one act on that screen a server cannot perform at all, and the desktop guards its revocations with a tooltip, which is a control a touch screen cannot show. Two defects were found by an adversarial pass and both were green against the whole suite at the time. The owner-only check on archiving and handing over had been weakened to the admin check while their messages and comments still said owner — and since nothing behind the archive endpoint re-checks it, an admin the owner had promoted could have archived the team out from under them. And the rename endpoint built its response with a hardcoded Owner role, so an admin who renamed a team was handed a summary claiming they owned it, and a client trusting that instead of re-listing would have offered them the two owner-only buttons the server then refuses. The new table gets its constraints tested rather than merely migrated: live uniqueness per (team, address), the citext proof that an address typed by a person matches one cased by a provider, and reissue after both revocation and acceptance. The teams screen gets its first entries in the layout suite, at the minimum window with every list populated and with each of the two states that cover half of it — it had none, and it just grew four sections and a second line in the member row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 14:31:43 +02:00
jaap-janandClaude Opus 5	8c04ba60b0	Build the three things the phone's + needs, before the + exists ... Steps 1 to 3 of docs/adding-hosts-on-the-phone.md: the domain half. Nothing on either head has changed, which is deliberate — the plan orders these first because everything the editors will bind to has to exist and be merge-safe before a screen can offer it. HostGroupSecret gains a parent and four defaults, and the codec gains the version rule it never had. It stamped CurrentSchemaVersion unconditionally, which was harmless with one field and one version and stops being harmless here: upgrading one machine and renaming any group would have made that group uneditable on every machine still on the old build. It now emits the lowest version that loses nothing, so a flat group with no defaults still encodes at version 1, byte for byte, pinned against a literal. Tags become a real item over the reserved slot. Secret, codec, merge, cipher, repository, both registries, the EF entity and a generated AddTagItem migration. TagCipher names AadResourceType.Tag as a constant rather than casting the wire type, because Tag is 5 on the wire and 8 in the crypto enum and 5 there is Credential — a cast would seal every tag under the resource type for a password, encrypt and decrypt perfectly on the machine that wrote it, and only fail when another implementation refused the item, by which time the AAD is frozen into stored ciphertext. HostTag stays reserved and unused: the one thing the join buys over a set on the host is bought instead by merging TagIds per id. HostSecret grows TagIds and Port goes nullable, which is the change with the widest blast radius and the only one that loses an item rather than locking one. A host with no port of its own omits the property, an older build reads int Port as 0, and TryValidate refuses it — unreadable rather than read-only. That cost is confined to hosts which actually inherit, because the version is a maximum over the fields present; the alternative, writing 22 into every host, is the lie inheritance exists to stop telling. One decision the plan did not specify. "Three states where there were two" is four — key, credential, typed password, or the group's answer — and two nullable ids carry three. Naming neither id now means inherit, so AsksForPassword says "a typed password even under a group that lends a key" out loud. Only true is ever written and a decoded false folds back to null, so a host that never touched it encodes as it always did. Nothing already stored changed meaning: no group could lend a binding before this build, so every existing host resolves exactly as it did. HostInheritance is the resolver, and its visited set is load-bearing rather than defensive. Two clients can each re-parent A under B and B under A while offline; the merge sees one item against one item and the server sees ciphertext, so nothing upstream can refuse the pair. With inheritance the chain is walked at connect time, so an unguarded cycle is not an undrawable sidebar — it is a shell that never opens. Stopping at the first repeat degrades it to a group that reads as a root, and clearing the parent is the repair. A tag set turns out to be the one field on a host that can never ask the user anything. TagSet.ToIdMap keys by the value, so no key can hold two values, so the both-sides-moved-differently branch of the keyed merge is unreachable — asserted over the whole eight-row matrix. The conflict loop is kept anyway, because that proof is one edit from ceasing to hold and what it would cause is a discarded tag nothing records. Three guard tests failed by design and were fixed rather than relaxed: the ordered pull filter, the AAD pinning table, and the server's refusal of a plaintext parent — that last one survives with its reason rewritten, because the refusal now means "the parent is not the server's to hold" rather than "there is no such thing as a parent". The prose that said groups are flat is rewritten in all four places it appeared, not deleted. The five view-model sites that read Port directly now go through the resolver, which is a down payment on step 4 rather than the whole of it. HostFields.From still emits the stored port, and that is the one remaining place where an unresolved read would be a wrong wire rather than a wrong label. Verified by the whole suite: 1382 tests over nineteen projects, none failing. Both heads build. Nothing seen on a display, because nothing on a display has changed yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 10:21:02 +02:00
jaap-janandClaude Opus 5	093f3904c1	Apply pending migrations at startup instead of asking for a second command ... The API deliberately never migrated: it failed readiness while a migration was pending and named it, and a separate step applied them. That is the right split for a deployment with a release pipeline and the wrong one for a self-hosted server, where it means an image that boots, refuses traffic, and waits for somebody to know that dotnet ef exists. The schema and the code that expects it ship in the same image, so the image is where the two are reconciled now. Before RunAsync rather than in the background. A migration racing the first requests would let them through against a half-applied schema, and the first authenticated request is the one that provisions accounts. Failing to migrate therefore fails to start, which is the loudest signal available and the one an orchestrator already acts on. Concurrent starts take a Postgres advisory lock first. Without it two replicas rolled out together read the same empty history table, both apply the same migration, and the second dies on an object that already exists — a crash loop on the day of a schema change, which is the worst day to have one. The lock is held on a connection of its own because EF opens and closes one per command, and a session lock belongs to the connection that took it. The exception is a database that does not exist yet: there is nothing to hold a lock in, so that path migrates without one and says so. Two instances creating it at once still converges — one wins, the other restarts into the ordinary locked path — and refusing to start would leave a fresh deployment stuck on the step this removes. Database:AutoMigrate turns it off for the deployments that own their schema: a migrator job, a rollout where new code must run against the old schema first, or a database user denied DDL. With it off the behaviour is exactly what it was, and the health check now explains which of the two situations a pending migration means. Verified against a throwaway PostgreSQL container: an empty database gets all seven migrations applied before the port opens, the tables land in the dodo schema, and a second start logs the schema up to date and serves. The API suite passes, which exercises the startup path once per assembly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 21:12:22 +02:00
jaap-janandClaude Opus 5	8a568117df	Give the API an image, and unbreak the restore that had to run first ... registry-docker.dodotech.cloud/dodotech/dodossh-api, built and pushed by a third ci job that needs the first. Gating on the tests costs a few minutes on every main commit and buys the only thing worth having here: an image is not an artefact somebody inspects before using it, so a red commit must not be able to produce one. Pull requests build the image and stop, which is where a broken Dockerfile should be found. Tags are :sha-<short> on every build, :main on main, and for a v* tag :1.2.3, :1.2 and :latest — the last two only when the version has no prerelease suffix, since v1.3.0-rc1 sorts above v1.2.9 and would otherwise walk :latest onto somebody's server. Only sha- is immutable, and it is the one to pin a deployment to. No docker/* actions. The build is single-architecture, so it needs the daemon this runner already has for the Testcontainers suites and nothing else — no buildx, no QEMU, and no third-party action whose SHA has to be audited and re-pinned. Step outputs and secrets reach the shell through env rather than ${{ }} interpolation, because a git tag may contain a semicolon and interpolation is textual substitution performed before the shell parses the line. The image is chiseled: no shell, no package manager, uid 1654. Affordable because Directory.Build.props already sets InvariantGlobalization, so the ICU and tzdata a normal base carries are exactly what this product decided not to use. The cost is stated in the Dockerfile rather than hidden — there is no HEALTHCHECK, because there is nothing to run one with, and /healthz/ready is anonymous precisely so the orchestrator can ask instead. Nothing migrates the schema from inside the container either; readiness fails while a migration is pending and names it, which is the design. And the restore that all of this depends on did not work. 7a3a521 committed lock files carrying a net10.0/android-arm64 section into fourteen projects — written there by the Android head's -p:RuntimeIdentifier=android-arm64 packaging build, which restores the shared projects with a RID and updates their lock files as a side effect. Any restore without that RID then fails NU1004 in locked mode, which is every other build there is: `dotnet restore DodoSSH.slnx --locked-mode` has been failing for eleven projects on a clean checkout of main since that commit. The sections are removed here and nothing else changed — deletions only, ILLink.Tasks stays at 10.0.10. Verified: the solution restores in locked mode, the image builds, and it runs. /healthz/live answers 200 and /healthz/ready answers 503 naming the database it cannot reach, from a 67 MB image as uid 1654, configured entirely through DODOSSH_-prefixed variables. The Android head's own lock file still carries the RID and is untouched, because that job restores it separately and is outside DodoSSH.slnx. Whether its packaging step re-dirties these fourteen on every CI run is worth a look; it is the same mechanism. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 13:40:12 +02:00
jaap-jan	5cbda59a34	Merge branch 'main' into claude/host-management-ui-plan-7f20ab ... Seven files needed a hand. Most were two branches adding something in the same place, but three were one branch changing what the other had moved or renamed, and those are the ones worth reading. The shell keeps both new fields and both constructor lines: the connection recorder this branch built and the teams view model main did. Where main put a teams load inside OnScreenChanged, it now sits beside the logs refresh rather than inside RaiseSurfaceState — this branch extracted that notification block and it is called from two properties, so a screen-specific side effect in there would fire on every terminal switch as well. Main gave four row types a vault id and a vault name, and this branch had moved one of them — KnownHostRowViewModel — into its own file when the pinned keys became a screen. Git resolved that as "deleted here, modified there" and took the delete, which compiles as long as nobody looks: the moved copy still had the two-argument constructor and the call site had grown to four. Carried over by hand, along with the ordering the pins list now does on them. The status line's quiet rule was the subtle one. Main extracted it into IsWorthReporting; this branch had changed the same condition to read item counts rather than raw ones, because every user action queues a log entry a moment later and this machine reads its own entries back on the next pull. Take main's structure and the merge builds, passes, and silently restores a bug this branch existed partly to fix — every save's message overwritten a second after it appears. The method now reads PulledItems and PushedItems, with the reason in its remarks. Two conflicts were prose that had gone stale rather than code. The keychain screen's comment said team vaults are refused by the server's access service, which was true when it was written and is not now; main's replacement stands, in this branch's vocabulary. The design-gaps row for groups was claimed by both — real host groups here, per-vault headings there — and they are different things, so both rows stay and the difference is stated: a group is a shelf the user chose, a vault is who can read the item. One defect the tests found and the compiler could not. Generating a key opens the same editor as pasting one, but not through NewKey — so it never set the target vault main added, and a generated key was filed into whatever vault was edited last, or none. Both key-generation tests failed on it. Fixed where the editor opens, with the reason recorded there. One gap is left deliberately and is written down rather than half-built. Hosts, keys, credentials and pins are read across every vault this session holds a key for; groups are read from the active vault alone, so a host a teammate filed shows under UNGROUPED. Nothing is lost or misfiled — it is what the sidebar already shows for a group that has been deleted — but closing it needs a vault id on every group row for rename and delete, and a way to tell two vaults' identically-named groups apart under a layout with one heading per group. Both are worth doing and neither is a merge's business. It is in the remarks on ReloadGroupsAsync and in docs/design-import-gaps.md. dotnet build, dotnet test and dotnet format --verify-no-changes are all clean: 1282 tests, including the end-to-end suite against real containers.	2026-07-31 20:44:39 +02:00
jaap-jan	d07b336868	Free the terminal from the Hosts screen, and fill the room it left ... The WebView sat inside the Hosts grid, so navigating to Files or the keychain hid every open terminal and the strip that named them. A connection you had opened was invisible from four of the five screens. The window now has two surfaces rather than one: a nav rail that says which page you are on, and a terminal strip that is always there and switches the whole content area to a shell. Screen keeps meaning "which page" and never becomes a sixth kind of page, which is why this is two properties instead of one enum with a terminal member in it. Every screen lives inside one wrapper panel that collapses when a terminal is showing. That is not tidiness — the WebView hosts a Win32 child window that composites above everything Avalonia draws, so a screen left visible over its rectangle is a screen sliced in half, and this window has shipped that defect once already. One decision point, IsTerminalShowing, and a nested panel rather than five compound bindings nobody would remember to extend. The focus choreography is the part no test in this repo can see. Every reveal path now focuses in the same turn the WebView appeared, so all three of them post at DispatcherPriority.Loaded and let the native control re-push its bounds first. Going the other way had a real bug: the screen-changed branch called a bare Focus() where it had to release the keyboard from the native child, so switching from a terminal to Files silently ate the first keystrokes. Rare before this commit and the primary gesture after it. The tab strip grew a cross inside each tab, a plus that opens the quick-connect palette, and middle-click close. Nested buttons are correct here: Avalonia handles a left press on the cross and deliberately does not handle other buttons, which is exactly what lets middle-click bubble up from the cross as well as the tab. The test is PointerUpdateKind rather than IsMiddleButtonPressed, because the latter reports button state and is also true for a left press made while the middle button happens to be held. The handler is on the tab and not the strip, so the background closes nothing by construction. Plus opens the palette rather than a flyout, since a menu dropping into the WebView's rectangle may or may not composite above a child HWND and this repo does not make rendering claims it has not photographed. Everything a user reads now says keychain. The wire, the database and the cryptographic spec still say vault, deliberately: renaming those is a migration and a protocol change for a word. That split is written down rather than left to be rediscovered as an inconsistency. Four things that were squeezed into the keychain's category rail, or into nothing at all, now have screens. Pinned host keys get one, with fingerprints never truncated and a filter that matches them, because comparing what you have against what the operator published is the whole workflow; the approved date is read out of the item's UUIDv7 rather than added as a column, and says so, since it means first approval and not last use. Keys can be generated in the client, which needed the openssh-key-v1 container written by hand — there is no BCL or NSec helper, and the PKCS#8 route is unverified in the SSH library this uses. The armour carries no passphrase: encrypting it needs bcrypt_pbkdf, which is Blowfish with a swizzle, in a project whose crypto is otherwise entirely libsodium, for a protection the key's own remarks argue is redundant inside a vault. Generation fills the existing editor and stops, so SAVE stays the one thing that writes. ~/.ssh/config can be imported behind a preview that is ticked per row and writes nothing until the button; IdentityFile records the path and imports the key material only on an explicit opt-in, because reading somebody's private key into a vault is precisely the act this product exists to make deliberate. Match blocks and ProxyJump are reported rather than obeyed — one cannot be evaluated statically and the other has nothing behind it to route with, and a preview that implied otherwise would be worse than one that admits it. Files can be dragged in all four directions that are honestly available. Remote to Explorer does not ship and is not pretended to: the shell wants the bytes during the drop, which needs a virtual file and a native COM data object, outside what Avalonia offers. Note for the next person that Avalonia 12 replaced the drag model outright — DataObject and DataFormats are no-op stubs and IDataObject is not in the reference assembly, so every tutorial written for 11 does not compile here. Hosts can be grouped, flat and never nested. A parent id merged as a scalar lets two offline clients each re-parent A under B and B under A, producing a cycle inside an encrypted payload that no server can police and every reader would have to detect for ever. Membership lives in that payload rather than in the one plaintext concession ADR 0001 allows, whose test is that the relay cannot function without it — nothing on the server reads a group, so what plaintext would hand over is a clustering of the estate for nothing. The plaintext column reserved for it is dropped, provably always null, and the server now refuses a client that sends one; it was never populated, was copied on apply, and was not cleared on delete, so a group id would have outlived the host it described. Snippets insert through xterm rather than through the pump, because xterm is the only thing that knows whether the remote has bracketed paste on, and that is what makes a shell treat embedded newlines as text instead of as execute. The host process moves opaque bytes and never parses output, so it would have to guess, and guessing wrong runs every line. Running is off by default and the copy says the text goes into whatever is there — the terminal has no notion of being at a prompt, and may be in vi or at a password prompt with echo off, so the Enter the user presses themselves is the entire safety property. Connections and keychain changes are recorded as synced encrypted items, which is what makes them auditable by a team later and costs the server knowledge of connection rate and timing from row counts alone. ADR 0001 already concedes it cannot hide that class of metadata; the trade is now written into it rather than left implicit. A connection entry is written once, at close, which is what makes a synced log tractable: nothing to merge, one outbox row, no chance of colliding with itself. Live sessions come from memory, not from the log. The write is void by contract and posts to a bounded channel, because putting an encrypt-and-write on the teardown path of every session is how closing the application comes to take four seconds. A ticket opened before a lock still closes afterwards, since a shell outlives the vault. The activity log hooks the one generic repository every kind writes through, so it cannot miss a caller — which is also why the log kinds themselves declare they are not audited, or the first entry would write an entry about writing an entry. It records the names of the fields that changed and never their values; a log with an old password in it would be a plaintext credential store with no vault around it. Retention is 90 days or 5,000 entries, whichever bites first, pruned on the sync loop rather than on a second timer. That log traffic then broke the status line, which is worth recording because the fix is a shape and not a patch: background sync counted its own log rows as pushed items, so the quiet rule stopped being quiet and every action's message was overwritten a second later by a sync report. The report now separates log rows from user items and the rule reads the latter. S3 buckets appear as a remote in the file browser, behind the same interface an SFTP session implements, so the queue and both panes did not have to learn what they are talking to. Uploads go through a pipe, because the queue wants to write and the SDK wants to read; memory is then bounded by the part size instead of buffering a file to disk twice. Finally, the Windows device key store moved out of the session project, which was the one thing keeping it from being portable — everything else in it is platform-neutral, and a Windows CNG dependency in the middle of the vault code meant a second head could not reference it without dragging Windows along. The seam that made the move free was already there. docs/android-port.md is the audit behind that: what ports, what does not, in order of cost, the four decisions taken, and an inventory of every screen and state the interface has to carry, written so a design can be made from it directly. dotnet build, dotnet test and dotnet format --verify-no-changes are all clean: 1240 tests at zero warnings, including the end-to-end suite against real containers. The manual checks that headless Avalonia cannot make — the drag from Explorer, a generated key against a real host, twelve tabs at the minimum window width — are listed in docs/manual-checks.md and are still outstanding.	2026-07-31 20:30:05 +02:00
jaap-jan	95816de0c5	Share a vault with a team, without the server holding a key ... M3's teams, sharing and ACLs. Teams with roles, a public-key directory, the append-only key log served for clients to check it against, team-owned vaults, and vault key grants wrapped by a client and stored opaquely by the server. VaultAccessService resolves team membership to PermissionFlags, so a viewer may pull and may not push; the desktop client reads and syncs every vault it holds a key for, and a real TEAMS screen replaces the one that said it did not exist. No migration: team, team_membership, vault.team_id and vault_key_grant have all been there since the first one, which is what carrying two unused tables bought. Membership is authorisation. A grant is access. The obvious model is one concept — "access", with a role attached, handed out by the server — and this architecture cannot implement it: a vault key is sealed to each member's X25519 key, and only a client holding the plaintext can seal it for somebody else. So "give Bob access" decomposes into a database write and a wrap, which happen on different machines. Adding a member makes the server serve them the vault; it cannot make it readable. VaultSummary.WrappedVaultKey is null in the meantime and the vault appears in their list saying it is waiting for a key, because hiding it until a grant existed would have been tidier and would have implied the server was the thing granting access. The screen says the same thing after every add, in the status line. ADR 0009 records the whole decision. Sharing verifies or refuses. A directory lookup is a claim by the server about a third party's public key, and wrapping to an unverified claim hands the vault to whoever made it — no amount of transport security helps, because the server is inside the threat model. KeyLogAudit reads the whole log, recomputes every entry's hash from its own contents, checks the chain from genesis, and refuses unless the offered key appears in it unchanged. There is no override flag: one that exists gets used on the day the log is briefly unreachable, and the resulting grant is indistinguishable from a correct one afterwards. What it still cannot promise is that the key is the right person's, so the fingerprint comes back for an out-of-band comparison and the success message says so every time. A test corrupts the fake server's log by one byte and watches the client refuse rather than warn. The roles are only the ones that are enforceable. There is no ConnectOnly, despite the design asking for one and TeamRole having room: SSH terminates on the client, so a session needs the credential's plaintext on that machine, and "may connect but may not read the key" cannot be enforced here. Shipping it as an option in a dropdown would have been a lie. Connect rides along with Read and is documented as an interface hint. Removal is named for what it does — it revokes grants and flags the vault for rekey, and claims nothing about what is already on somebody's laptop. Three things are deliberately absent, and each is a refusal rather than an omission. The rekey itself, because re-wrapping every item's data key under a new vault key needs a client holding the current one; the server records that a rotation is owed and the interface reports it, which is more honest than a button that only appears to do it. Ownership transfer, because allowing an owner to be removed without one leaves a team nobody can administer. And cross-vault host key trust: a pin in a team vault is listed but not consulted at connect time, because any member with Write could otherwise pre-approve a fingerprint another member's client then trusts silently for a host in their own vault. Scoping trust properly needs a scope on the SSH connect path, which IKnownHostStore has not got; until then the narrow direction is the safe one and the cost is in the README rather than hidden. Reading now spans vaults and writing still does not. Every list on the vault and hosts screens covers each vault the keyring opened, rows carry the vault they came from, and an edit goes back to that vault rather than to the active one — writing it to the active vault would fork the item and only show up when a colleague wondered why their change never arrived. A new item goes wherever a picker says, defaulting to the personal vault and never moving on its own, because an item filed into a team's vault is visible to that team and moving it back means deleting and retyping. The sidebar heading stops naming one vault once there are two, and each row names its own. The server checks what it can and nothing it cannot. It will not record a grant for a key its recipient no longer holds, for a superseded generation, or for somebody who is not in the team — each of those would otherwise surface days later at the far end as a tag failure indistinguishable from corruption. It does not verify the wrap or the signature, and the grant service says so: that would be a convenience and never the boundary, and would put an asymmetric implementation on a machine that is supposed to hold no keys. Two bugs the tests found. TeamsViewModel's busy gate blocked its own reload, so a team created a moment earlier was missing from the list it had just been added to. And syncing every vault turned a failure from an exception into a report, which made a background pass announce an unreachable vault once a minute — the exact behaviour AnAutomaticPassThatFails_LeavesTheStatusAlone exists to prevent. The fact is recorded and the message swallowed, as it was before; pressing Sync still names the vault and the reason. Also fixes a build break this branch started with: QuickConnectTests was never updated when M2 added ISftpSessionFactory to the shell's constructor, so nothing built at all.	2026-07-31 12:18:28 +02:00
jaap-jan	94e11f5e38	update packages	2026-07-31 10:12:05 +02:00
jaap-jan	9bc28f1c0f	Move the API onto FastEndpoints, without moving the wire ... Eight endpoints today, around sixty planned. The minimal-API shape — a static class per area holding static local functions, route and policy and name asserted in one fluent chain with the handler somewhere below it — has not hurt yet, and would. A handler's dependencies are parameters rather than injected, a group's RequireAuthorization sits far from the handler it governs, and there is no type to hang an endpoint's own documentation on. FastEndpoints is one class per endpoint, its route and authorization in Configure(), its handler a method on the same type. Nothing about the wire moves, and the evidence is that the 94 existing HTTP tests pass with zero edits to any of them. Same routes, verbs, route constraints, status codes, operation ids, and the same RFC 9457 bodies with the same code values. Every place the idiomatic FastEndpoints answer would have changed one of those, it was refused: Endpoints are registered from an explicit List<Type>, not found by scanning. ADR 0002 rejected reflection discovery by name, and the reason it gave is sharper here than in general — under WebApplicationFactory the scan reaches the test assembly, so an endpoint written in a test would be registered into the host under test. The cost is a line per endpoint that can be forgotten, which is what the endpoint-inventory test is for. That test is the one ADR 0002 promised and never got. Handlers still return Results<Ok<T>, NotFound, ProblemHttpResult> from ExecuteAsync. The union executes as an ordinary IResult, which is what keeps problem bodies going through the host's serialiser and IProblemDetailsService, and what keeps the compile-time record of which statuses an endpoint can produce. No Send.* call appears anywhere; the moment one does, a response has left the host's serialiser. Validation stays in the feature services. A Validator<T> short-circuits before the handler and answers with FastEndpoints' own envelope, which carries no code — and the code is the only part of an error the client branches on. Twenty-odd tests assert a specific code on a 400. It is banned in BannedSymbols.txt rather than merely avoided, because the framework's documentation leads straight to it and it looks like an improvement. Three defects arrived with the framework and were caught in review. All three were green at the time, which is the part worth remembering. FastEndpoints maps GET /_test_url_cache_ unconditionally, in every environment, with no policy and no way to opt out; it answers with the whole endpoint-name-to-route table. It is short-circuited to 404 — by asking routing which endpoint it selected, after the first attempt compared the request path with Ordinal and was therefore bypassable at /_TEST_URL_CACHE_, certified by a test that only ever tried one spelling. The default request binder writes query-string values over the deserialised body, which would have let ?identityProviderToken=... put an ID token in a URL and from there into every proxy log on the path; every endpoint now binds from the body alone. And a route value read with Route<T>() is invisible to ApiExplorer, so the generated document named {vaultId} in a path template with nothing declaring it — invalid OpenAPI, and unusable by the client generators the document exists for. Two changes to the surface, both deliberate. A body that cannot be deserialised now answers with a problem document carrying malformed-request, rather than an empty 400: FastEndpoints' default announces application/problem+json while sending something else, and names the failing .NET type on the wire, in a codebase that sets IncludeErrorDetails = false to prevent exactly that. And the route table above returns 404 where it would otherwise have answered any authenticated caller. Each of the three fixes has a regression test that was checked by reverting the fix and watching it fail — four failures for the route table and the binder, four for the document. That check is the whole reason to trust them, since all three defects passed a full green suite on the way in. 950 tests green across 16 projects, 14 of them new and no existing test edited. Zero warnings, format clean, locked restore clean. FluentValidation, JobQueues and Messaging are in the graph now and none is used. Not verified: the generated document's response schemas, which differ from before — FastEndpoints contributes its own Produces metadata. Nothing consumes the document yet, and MapOpenApi runs only in Development behind the fallback policy. It needs pinning if ADR 0002's build-time artifacts/openapi/v1.json is ever built.	2026-07-31 08:39:06 +02:00
jaap-jan	f86791e817	Finish revoking a device, instead of half of it ... ForgetDeviceAsync stopped this machine unlocking without a passphrase and left the server's row exactly where it was, so the account went on listing a device nobody could account for. ADR 0007 recorded that as a deliberate gap needing an endpoint. This is the endpoint, and the two things that turned up behind it. DELETE /api/v1/me/devices/{id}. The device row is not the dangerous half: a kind=device wrap is the user's identity bundle sealed to a key somebody may be holding, and that is what has to go. It goes on the foreign key's cascade rather than a second statement, and RevokeDevice_TakesItsWrapWithIt asserts the cascade rather than trusting the configuration to keep saying so. Scoped to the caller's own account, which is the only authorisation check there is. The id is an unguessable v7 GUID, but unguessable is not a permission — without the scope one user could withdraw another's device key by pasting an id they saw once, and the victim's next launch would ask for a passphrase with no explanation. 404 rather than 403 for somebody else's device, so a stranger does not learn the id exists. Never refused for being the last device. ADR 0001 makes an enrolled device a recovery path, so removing the last one does cost the user something — but the machine being revoked is most likely the one they have just lost, and a server that argued about it would be refusing the one request that has to work immediately. The passphrase wrap is untouched either way, which RevokeDevice_LeavesThePassphraseWrapAlone pins. --- Two things found on the way --- Registering twice from one machine left two devices on the account. The server is idempotent on the public key, but the client generates a fresh key pair every call and the keystore holds one — so the second registration orphaned a wrap whose private half had just been overwritten, which is precisely the leftover this change exists to remove. Registering now withdraws the previous device. Found by a test that asserted the property and failed. And the fakes were lying about it. FakeAccountServer's comment claimed the real service's idempotence while handing back a fresh Guid on every call, which is invisible until something revokes by id — at which point a test would be revoking an id the server never issued, and passing. Both fakes now issue one id per public key and drop the wrap with the device, as the cascade does. --- Reachable at all --- ForgetDeviceAsync had exactly one caller and it was a test, so "Stop unlocking here" now sits in the account bar where "Use Windows Hello here" was. Its own flag rather than the negation of that one: a machine with no TPM and a machine that is already registered are both "cannot register", and only the second has anything to take back. No confirmation prompt, deliberately. The cost of pressing it by accident is one passphrase and one re-registration; the cost of a dialog is a moment's hesitation at the point somebody has realised a machine is in the wrong hands. Offline it does the local half and says so rather than refusing. Whether this machine may unlock itself is decided entirely by the local cache and the local keystore — the unlock path never asks the server — so forgetting here is what actually revokes, and "you are offline, so this machine will go on unlocking itself" would be the worst available answer. DeviceRevocation.LocalOnly is what the interface reports and the status line explains what is left to do. The local half runs first for the same reason, and the keystore call is the first thing in the method that can yield: on Windows it raises a consent dialog, and a dialog wants the thread it was called from. That ordering is currently load-bearing and shakier than it looks — see the open device-unlock hang. Four mutations, all caught: dropping the user scope from the server query (1 test), skipping the stale-device revoke on re-registration (2), skipping the server call in ForgetDeviceAsync (2), and the earlier version of the client that never called it at all. 930 tests green across 16 projects, 13 of them new. Zero warnings, format clean.	2026-07-30 17:33:31 +02:00
jaap-jan	db4a8ed3d3	Let an already-enrolled account register a device key ... The first of the three pieces ADR 0007 needs, and the one that was a discovery rather than a plan. EnrollmentService.AddDevice runs only during enrollment, so without an endpoint the device-unlock feature would have reached accounts created after it shipped and no others — which is to say none of the ones that exist. The code even said so: "the devices endpoint sets it properly when it lands." POST /api/v1/me/devices takes a name, an X25519 public key and the bundle sealed to it, and writes a device row plus a UserKeyWrapKind.Device wrap. Possession is proved by construction, so there is no challenge. The wrap is the secret bundle sealed to the supplied public key, and only something that has opened that bundle can produce it. A caller who seals the wrong bytes registers a device that cannot unlock, which harms nobody else; the server cannot tell the difference and must not pretend to, because it holds no key that opens either. That is also why the client must be unlocked to call this at all. It is the one endpoint in the /me group that requires enrollment, and it says so itself rather than relying on the group. The group deliberately does not: GET / and POST /enrollment are how a client discovers it needs to enroll and then does so, and gating those on enrollment would make enrollment unreachable. Adding the stricter policy to this route alone means an unenrolled caller is told "enrollment-required" by the authorization handler rather than getting a 400 about the shape of a request that was fine. Idempotent on the public key, and 200 rather than 201 for the reason enrollment gives: a retry of an identical request returns the same body, so there is no single moment of creation to point a Location header at. A second row for one key would mean a device list with a duplicate in it and two wraps to revoke instead of one. Mutation tested — removing the lookup fails RegisterDevice_TwiceWithTheSameKey_ReturnsTheSameDeviceAndAddsNoSecondWrap and nothing else. That test also found a real defect, in the way these usually surface: two timestamps that print identically and are not equal. TimeProvider reports 100-nanosecond ticks and PostgreSQL's timestamp with time zone keeps microseconds, so the first call returned a value that no later read of the row would ever produce, and the idempotent retry answered with a different timestamp for the same device. Nothing breaks, which is what makes it worth fixing: the service now truncates to the precision the column actually holds, so the response is the same value every time it is asked for. The repo already had a precedent for this class of thing in KeyLogChain.TruncateTimestamp; it just had not been applied here. The platform is deliberately not carried on the wire, which leaves Device.Platform unreported and the stale comment corrected rather than fulfilled. It would be a display-only field, and a Contracts enum mirroring the domain's DevicePlatform is exactly the shape of duplication that has produced three self-consistent bugs in this repository. A device list that wants it can add a mapping table and a test pinning the two together, which is what the sync entity types already do. Its own problem code and exception rather than reusing enrollment's, whose rules it largely shares. Registering a device is not enrolling, and a client showing "your enrollment was rejected" because somebody set up a fingerprint reader would be describing the wrong thing. The validation shares the limit constants — MaximumWrapBytes, MaximumDeviceNameLength, PublicKeySize — and not the four-line guards, which would have had to be parameterised over which exception to throw for less than they cost. Both in-memory fakes implement it properly rather than throwing: they record the wrap so a test can assert it arrived, and refuse before enrollment as the real endpoint's policy does. A fake that answered where the server refuses is a fake that can make a real bug pass. 866 tests green, 8 of them new. Zero warnings, dotnet format clean. Still to come: the protector seam with the wrap cached locally so device unlock works offline, then the Windows Hello implementation and the unlock-screen UI — which is where the Windows target framework lands and where automated testing stops.	2026-07-30 13:18:09 +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	e24012b039	Sync credentials as a vault item type, and bind one to a host ... Closes the largest remaining M1 gap in the data layer: a username and password can live in the vault, sync between machines, and be named by a host as how it authenticates. What is not here is the interface for creating one — see the end of this message. The third item type, and the first one that cost almost nothing to add. Server: a VaultCredential row, an EF configuration, a migration, and a CredentialKind. Client: a secret, a codec, a merge, a cipher, a kind, a repository facade and a session property. No new reconciliation logic, no change to the sync engine, no client cache migration. That was the whole point of the item-kind seam, and this is the evidence it holds. The narrowest type of the three on plaintext, and not for symmetry. A host has a deliberate concession — the relay needs an address it can resolve. A key has a fingerprint, public by nature, which this client still declines to send. A password has no part that is safe to expose: not its length, not a hash, not a hint. So CredentialKind refuses every plaintext field there is, hydrates none, and the table has no column to put one in. HostSecret.CredentialId is the password counterpart of SshKeyId, and the two are mutually exclusive. SSH itself would happily try a key and fall back to a password, but a host naming both leaves "how does this authenticate?" without a single answer — the interface, the connect path and the user would each be free to guess differently. TryValidate refuses it. One consequence was not anticipated: "a full host" stops being a coherent idea, which is what broke AFullHost_RoundTrips and is now written into that test. The schema version became a ladder rather than a maximum: credential-bound is 3, key-bound is 2, neither is still 1. Adding credentials therefore does not drag every key-bound host in every vault onto a version that clients understanding keys perfectly well would refuse to edit. A test pins exactly that, because it is the property the whole content-dependent-version rule exists to provide, and the obvious implementation would quietly lose it. Two tests had become false and said so: - Push_AnUnsupportedEntityType_IsInvalidNotAFailedBatch used Credential as its example of a type this server does not implement. It now asks the server's own registry what is still missing, so it cannot go stale again, and skips with a reason if that set ever empties. - ThePullFilterNamesEveryTypeThisBuildSynchronises pinned the exact list, which is what it is for. Also fixes ten nullable warnings — eight in SyncEndpointTests, two in a test file added earlier today. Neither set was introduced here; both were invisible until an unrelated change forced their project to recompile, which means the zero-warning claims made earlier in this work only ever covered what happened to be rebuilt. 777 tests green. Zero warnings, dotnet format clean. Not done, and deliberately: the credential interface. The vault column is 340 pixels wide and already holds two lists and two editors, kept from clipping its own buttons at the window's minimum height only by the one-editor-at-a-time rule added earlier today. A third list and a third editor would recreate that defect rather than avoid it, so the column needs a shape decision first. Credentials sync; they cannot yet be created in the interface.	2026-07-29 21:09:08 +02:00
jaap-jan	e93acc856f	Sync SSH keys as a vault item type, over a shared write path ... The private key now lives in the vault as ciphertext, syncs between a user's machines, and is stored on the server so it can later be shared — sharing itself needs M3's signed grants; this is the storage that makes it possible. More was already reserved than expected: SyncEntityType.SshKey, CryptoSpec.AadResourceType.SshKey, ChangeEntityType.SshKey, SyncPlaintextFields.PublicKeyFingerprint, and SshPrivateKeyCredential wired through PrivateKeyFile over a MemoryStream so a key never touches disk. The frozen contract and crypto spec needed no change at all. What was missing was the server. Rather than copy the push path per item type — version check, change-log append, exactly-once receipt, advisory lock — it is now written once over IVaultItem, with everything type-specific behind IItemKind: which table, which plaintext columns, and what those columns must satisfy. Ten copies of that logic by M5, with a fix applied to nine, is the outcome this avoids. The refactor landed first with no behaviour change, so all 66 existing Host tests were the regression net, and they stayed green. An interface rather than a base class, deliberately: EF Core maps an inheritance hierarchy when it can see one, so a mapped base would quietly become a table-per-hierarchy discriminator across item types — the very arrangement per-type tables exist to avoid. ssh_key mirrors host and pointedly has no relay trio. That is the argument for separate tables rather than one wide item table: the columns a host needs are columns a key must never have, and a shared table could only make them nullable and trust the code. A key carrying a relay target is refused with a reason rather than silently dropped. A key hydrates PlaintextFields as null, not an empty instance — the difference is visible on the wire, because an all-defaults instance still serialises "relayEnabled": false and invites a reader to believe the setting exists and is off. It has none. Two things now defended by tests rather than by comments. Each kind states its own ChangeEntityType instead of casting: the two enums agree numerically but do not even share member names (Host against SshHost), and filing key changes under the host type is silent sync corruption — sabotaging it fails three tests. And EntityTypeAlignmentTests asserts the two enums stay aligned in both directions and in count, which nothing did before. The client half is next: SshKeySecret, its codec and merge, the cipher, a repository, and the UI. Note for that work — SyncEntityType.SshKey is 3 while AadResourceType.SshKey is 6, so a cast between them would seal key ciphertext as a vault and nothing would fail.	2026-07-29 15:14:06 +02:00
jaap-jan	1d262b7ccc	Run M1's end-to-end slice, and fix the two bugs it found ... The whole vertical slice now runs against a real Keycloak, a real API, a real PostgreSQL and a real sshd: sign in through the browser flow, enroll with the identity-provider key binding, unlock, create a host, sync it, read it back on a second machine, unlock again with no network, accept an unseen host key, and open an interactive shell. Opt-in, because it needs the development stack; skipped with a message naming the commands. It found two bugs on its first run, and both are the same class: two sides of a stub agreeing with each other about something the specification never said. **The API never applied DodoSshJsonContext to its HTTP JSON options.** Minimal APIs therefore used the framework's web defaults, which write an enum as a number. Every request DTO carrying one failed to bind against a client writing the specified string form — which is the entire sync surface, unreachable from the real client, with a 400 naming only the parameter. The documented guarantee that request bodies reject unmapped members was likewise not in effect anywhere. Nothing caught it because the API tests posted with PostAsJsonAsync's defaults, so they and the server had independently settled on integers. Those tests now serialise through the contract, which is the deeper fix: removing the new configuration fails 13 of them. Copying settings into options a host owns is itself the hazard the context warns about, so ApplyTo lives beside the settings it mirrors and ApplyToTests pins the transformation, including that inserting the resolver leaves the caller's own in place. **The realm registered a loopback redirect URI Keycloak rejects.** `http://127.0.0.1:*/callback` looks more explicit than the RFC 8252 form and is broken: Keycloak's wildcards are trailing-only, so the `*` parses as a literal port and every authorization request came back "Invalid parameter: redirect_uri". Providers ignore the port for loopback hosts, which is the whole mechanism, so the correct registration is `http://127.0.0.1/callback` — path pinned, port free. The value the server advertises through the discovery document said the same wrong thing and now says the right one. Two smaller things, both documented in docs/platform-flags.md: - --import-realm skips a realm that already exists, so editing the realm file and restarting Keycloak changes nothing and serves stale configuration. The container has to be recreated. The compose comment claimed the opposite. - Keycloak marks its session cookies Secure even over plain HTTP, because SameSite=None requires it. A spec-conformant client drops them and the login POST answers 400 with no message; browsers complete the flow only because they exempt loopback. Harmless for the product, fatal for automation, so ScriptedBrowser carries the cookies by hand and says why. Also: the server enforces a 64 MiB floor on the passphrase KDF, so this suite cannot use the 8 MiB profile the other client suites take for speed. Those only get away with it because their in-memory servers have no policy — worth knowing rather than rediscovering. 638 tests. The solution-wide run stays green with the stack down: exit code 8 means "no tests ran", which the platform reports as failure, so the opt-in project ignores exactly that code.	2026-07-29 11:37:49 +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
jaap-jan	a628762cd1	Add /me and enrollment with the identity-provider key binding (M1) ... The last backend piece of M1. A client can now log in, discover it must enroll, publish its identity key, and get a usable personal vault. Enrollment is one indivisible act. One transaction writes the key, its wraps, the device, the key log entry, the vault and the vault key grant, because none of them is useful alone: a key with no vault leaves a user unable to store anything, and a vault with no grant is a container nobody can ever open -- including its owner, since only the client can wrap the key and it has already moved on. Two independent checks run, and neither substitutes for the other. The Ed25519 self-signature proves possession of the private key. The identity-provider binding proves whose key it is: the client hashed its statement, used the hash as an OIDC nonce, and the resulting ID token is the provider's signature over exactly those public keys. This server cannot mint that signature, so it cannot invent a key for a user who never enrolled -- which is the attack that would otherwise let an operator read every vault by publishing its own key as yours. The binding token is stored verbatim, not just summarised. Clients must repeat the check against the provider's JWKS fetched directly, and storing only our conclusion would ask them to trust the server about the one question the design exists to avoid trusting it about. Key log appends take a deployment-wide advisory lock. The falsification matters more than the passing test: with the lock removed, Enroll_ConcurrentEnrollmentsByDifferentUsers_LeaveAnUnbrokenChain fails with entry 11 linked to the wrong predecessor. Different users trip no unique index, so without serialising they all read the same head and the chain forks -- indistinguishable from the key substitution the log exists to make detectable, and permanent, because the log is append-only. Enrollment is idempotent. Vault ids and keys are client-chosen, so a client whose response was lost re-sends the identical body and gets the identical result. Without that, a lost response leaves a user enrolled against a vault they never learned the id of. Contract change, breaking the v0.1 freeze deliberately. EnrollmentRequest had DevicePublicKey but no wrap to go with it, which is unsatisfiable: only the holder of the secret bundle can seal it, so the server could never fill the gap. Added DeviceWrappedPrivateKey, and PersonalVault so enrollment can be atomic rather than leaving an unopenable vault behind two endpoints that do not exist yet. No client exists and no package is published, which is exactly when PublicAPI.Unshipped.txt expects this. Sync now requires the Enrolled policy, which until now was a stub whose name promised a check it never made. The sync denial tests use enrolled intruders instead of unenrolled ones -- an unenrolled caller is stopped before the vault check runs, which would have left those tests passing without exercising the thing they exist to prove. Also fixed: omitting kdfParameters from the JSON body was a 500. A record's non-nullable parameters are a compile-time promise, not a runtime one. 268 tests pass, zero warnings on a clean rebuild, format clean.	2026-07-28 16:06:35 +02:00
jaap-jan	98d29bff37	Add HTTP integration harness and the sync authorization matrix (M1) ... 27 end-to-end tests over the real HTTP pipeline, against a PostgreSQL container and a stubbed identity provider. This closes the gap the previous commit flagged. Authentication is genuinely exercised, not bypassed. StubIdentityProvider serves real OIDC discovery and JWKS via WireMock and signs tokens with a real RSA key, so the application's own JwtBearer pipeline validates issuer, audience, signature, lifetime and claims. A TestAuthHandler that short-circuits authentication would hide exactly the claim-mapping mistakes that cause real authorization holes. Proven by rejecting: no token, a foreign signing key, the wrong audience, the wrong issuer, and an expired token. Authorization denials — the tests that matter most: - Another user's vault is 404, not 403, for both pull and push. A distinct "exists but forbidden" answer is an existence oracle for other tenants' vault ids. - A denied push writes nothing: no host row and no change-log entry. A denial that still mutated state would be worse than no check at all. - A team vault is denied until M3 rather than falling through to a permissive default. Behaviour covered: push/pull round trip, cursor advance (and that an empty pull does not rewind the cursor, which would replay history), tampered cursor rejection, stale-version conflict returning server state without overwriting, operation-id replay reported Duplicate and applied once, a mixed batch applying the good and reporting the bad, relay field enforcement both ways, delete clearing the relay address, tombstones carrying no payload, and JIT provisioning happening exactly once. Two configuration problems found by running it: - appsettings.json carried empty-string placeholders for the connection string and OIDC authority. Under minimal hosting those beat anything a test registers via ConfigureAppConfiguration, because Program.cs adds its own sources after that callback runs. Removed them outright — an empty placeholder turns "not configured" into "configured as empty", which defeats failing fast. Tests now use DODOSSH_ environment variables, which Program.cs adds last. - My first fix for minting an expired test token derived notBefore from the expiry, which put nbf fourteen minutes in the future for normal tokens and made every valid token 401. It needs the earlier of now-1min and exp-1min. Verified: 0 warnings on a clean rebuild, 173 tests pass (up from 146), format clean.	2026-07-28 15:11:43 +02:00
jaap-jan	3829217e8a	Add sync engine: cursors, push/pull, and the advisory-lock ordering proof (M1) ... The vault write path. Push is the only way items change — no per-entity POST/PUT/DELETE — so one place enforces revisions, the change log and access control. The concurrency hazard, now proven rather than asserted: bigserial assigns sequence values when the INSERT runs, not at commit, so transaction A can take sequence 5 while B takes 6 and commits first. A reader polling in between sees only 6, advances past 5, and never learns about it. AdvisoryLockOrderingTests reproduces that gap WITHOUT the lock first — otherwise the with-lock test proves nothing, since it would pass just as happily if the interleaving never occurred — then shows pg_advisory_xact_lock removes it, and that 12 concurrent writers produce no gaps. Cursors are opaque and HMAC-tagged, and carry their vault id. 29 unit tests cover the rejections, which are the point: an accepted-but-wrong cursor is silent data loss, strictly worse than an error a client can resync from. Rejected: tampered tag, tampered payload, foreign signing key, a legitimately-issued cursor from another vault, truncation, and hostile input (never throws — cursors come from clients). Push semantics: - 200 even on partial failure, with per-operation status, so one stale item cannot block everything a client queued while offline. - Conflict returns the server's current row for client-side three-way merge. The server cannot merge ciphertext, so never last-writer-wins. - opId receipts make retries exactly-once per operation, not per batch — a client retrying a partially-overlapping batch after a timeout would otherwise double-apply what landed. - A tombstone beats a late upsert, and delete clears hostname/port: leaving the address would keep the server able to resolve a host the user believes they deleted. - Relay field validation mirrors the DB CHECK so a bad request is a clear Invalid rather than a constraint violation surfacing as a 500. Authorization goes through IVaultAccessService, which returns the same answer for "absent" and "forbidden" — distinguishing them is an existence oracle for other tenants' vault ids. Team vaults are explicitly denied until M3 rather than falling through to a permissive default. JIT provisioning keys on (issuer, subject), never email, and handles the concurrent-first-request race via the unique index. Renamed two domain types: Host -> SshHost, because Host collides with Microsoft.Extensions.Hosting.Host in every file of a web project, and SyncChange -> VaultChange to stop it colliding with the Contracts DTO of the same name. Aliasing at every use site would have been permanent friction. Worth noting: `ef migrations has-pending-model-changes` reported clean after those renames even though the snapshot still said "DodoSSH.Domain.Host" — it diffs tables, not CLR type names. The snapshot was regenerated and the emitted DDL diffed against the previous artifacts/schema/v0.1.sql to confirm the rename produced no schema change. Also removed ConfigureAwait(false) from test methods: xUnit1030 flags it as bypassing parallelization limits, which is why MA0004 is suppressed in test projects. Verified: 0 warnings on a clean rebuild, 146 tests pass (up from 122), format clean. Endpoint-level tests are the immediate next step: they need a WireMock OIDC/JWKS stub and real JWT minting, so the "wrong user is denied" matrix does not exist yet for these two routes. The service-layer authorization and the concurrency property are covered.	2026-07-28 15:02:02 +02:00
jaap-jan	d3b14e6bc0	Add configuration, OIDC auth wiring and discovery endpoints (M1) ... Options, JWT bearer validation, the /meta and .well-known endpoints, and a dev compose stack with Keycloak. Verified end to end: compose up, migrate, run, both discovery endpoints return correct payloads, and readiness reports the schema current. Configuration: - Strongly-typed options for Server, Oidc, Relay and Sync, all ValidateOnStart. A self-hosted server that boots half-configured and fails later per-request is far harder to diagnose than one that refuses to start and names the bad setting. - Cross-field validation the annotations cannot express: relay needs a WebSocketUrl when enabled, idle timeout must be under max session duration, item payload cap under batch cap. - Startup warnings for combinations that are individually valid but dangerous together: RequireHttpsMetadata false outside Development, and AllowEmailLinking (which turns any token bearing a victim's email into account takeover, hence default false). Auth: - JwtBearer with ClockSkew cut to 30s from the 5-minute default; five minutes of slack on a credential granting vault ciphertext access is more than any clock needs. - IncludeErrorDetails off, and a FallbackPolicy so an endpoint without an explicit policy still requires a caller rather than silently being public. Discovery, per ADR 0002: - /api/v1/meta reports versions, features and push caps. - /.well-known/dodossh-configuration is the onboarding story: the user types one server URL and the client discovers OIDC authority, client id, scopes and relay endpoint. Two environment problems found by actually running the stack: - PostgreSQL 18 changed its data mount point. Mounting /var/lib/postgresql/data — correct through 17 — makes the image refuse to start; 18+ wants a single mount at /var/lib/postgresql with the cluster in a subdirectory. - Keycloak moved to host port 18080. An unrelated Apache Tomcat on this machine holds 127.0.0.1:8080, and a loopback-specific bind beats Docker's 0.0.0.0 publish for "localhost". It presents as Keycloak 404ing every realm while its own log says the import succeeded, which is a genuinely misleading failure. Also: CA1848 is enforced, not advisory — warnings are errors, so the .editorconfig comment claiming otherwise was wrong. Startup and health logging now uses [LoggerMessage]. And a clean rebuild is back to zero warnings; the incremental build had been hiding 40 in test projects (banned Guid.NewGuid, an obsolete Testcontainers constructor, and two analyzer families that are genuinely noise under a test host). Verified: 0 warnings on a clean rebuild, 122 tests pass, format clean.	2026-07-28 14:33:54 +02:00
jaap-jan	3a81f3c90b	Restructure into src/tests and add build foundation (M0) ... Moves the scaffold to src/DodoSSH.Api and establishes the repo conventions the rest of the milestones build on. Structure: - src/{Contracts,Crypto,Domain,Infrastructure,Api}, tests/{Contracts,Crypto,Domain}.Tests - DodoSSH.slnx rewritten with src/ and tests/ solution folders Build: - Directory.Build.props centralises TFM, nullable, deterministic builds and TreatWarningsAsErrors; Directory.Packages.props pins every version centrally - packages.lock.json committed so CI restores in locked mode - NuGet.config clears machine-level sources, which both fixes NU1507 under central package management and makes restore reproducible off this machine - Microsoft.OpenApi pinned to 2.11.0: ASP.NET Core 10.0.10 resolves 2.0.0, which is covered by GHSA-v5pm-xwqc-g5wc (high, patched in 2.7.5) Analyzers: - AnalysisLevel is Recommended, not All. With warnings-as-errors, All turns opinionated naming rules into build breaks and trains people to blanket-suppress. - BannedSymbols.txt bans DateTime.UtcNow (TimeProvider), Guid.NewGuid (CreateVersion7), sync-over-async, MD5/SHA1, PBKDF2 and SecureString - CA1711/CA1724 disabled: both are .NET Framework CAS-era naming rules - PublicApiAnalyzers on Contracts only, since that assembly is the client's real contract API: - weather-forecast template removed - UseHttpsRedirection removed; TLS terminates at the reverse proxy and redirecting behind one causes loops - /healthz/{live,ready,startup}. Liveness deliberately checks no dependencies so a transient database outage cannot restart the container and kill live SSH sessions. Notes: - No coverage collector yet. Microsoft.Testing.Extensions.CodeCoverage pulls an MTP 1.x MSBuild extension that throws TypeLoadException against the MTP 2.3.x xunit.v3 brings. Coverage gates are an M3 concern; revisit with an MTP 2.x-aligned version then. Verified: dotnet build (0 warnings), 17 tests pass, format check clean, API serves health and OpenAPI endpoints.	2026-07-28 12:25:34 +02:00