126 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	b20f7cae04	Let a host marked for the relay actually be reached through it ... The relay checkbox said it was not wired up, and the plan said the server half was built and shipped. It was not: there was ADR 0004, the contract records, RelayOptions and a CHECK constraint, and RelayOptions said in its own remarks that there was no endpoint and no dialler. So both halves are built here, as step 3 of docs/reaching-a-host-you-cannot-dial.md. Server, in Features/Relay: - POST /api/v1/relay/tickets makes every decision: the host, Connect on its vault, the relay switched on, and the stored name resolved once and judged by RelayAddressPolicy. Loopback, link-local, 0.0.0.0/8, multicast and the metadata endpoints are refused with no configuration escape, with IPv4-mapped and NAT64 spellings unwrapped first; then the operator's denials, allow-list and private-network switch. What passes goes into a Data Protection ticket, and nothing resolves the name again. Every target refusal is the same 403, so the endpoint cannot be used to map the operator's DNS; the real reason is logged. - GET /api/v1/relay/connect takes the ticket as a second subprotocol, checks its expiry against TimeProvider and spends it with a unique insert into relay_ticket_use before accepting the upgrade. After the upgrade a refusal is a close code: 4502 for a host the server could not reach, 4429 for a limit, 4408 idle, 4409 lifetime, 1001 after a drain. - relay_session is the audit row, written from short-lived scopes. Client: - RelayBridge is a loopback SOCKS5 listener that accepts once and pipes to the relay socket. It rides on the new SshLoopbackProxy.Lifetime, so the connection disposes it on every way a session ends and a failed connect disposes it before throwing. - ServerRelay, exposed as IVaultServer.Relay from /api/v1/meta, asks for the ticket, opens the socket, starts the bridge and turns every refusal into a sentence. - VaultViewModel and TransfersViewModel reach a relayed host through it, never fall back to dialling it directly, and replace SSH.NET's transport error with the relay's own reason when it gave one. Neither side ever cancels a WebSocket operation. Cancelling one aborts the socket, and an aborted socket sends no close frame, which is the only way the client learns the server could not reach the host. AnIdleSession_IsClosedWithTheIdleCode asserts that the code arrives. Three departures from ADR 0004, recorded in it: awaited copy loops rather than Pipelines (same backpressure, two 32 KiB buffers), no ?ticket= fallback, and no device id in the ticket. Tests: API 245, shell 582 (5 skipped), layout 170, SSH 110 including a real login through the bridge, API client 30, contracts 25. Not run: the Android build (its change is copy only) and the Alpine layout oracle.	2026-09-28 14:37:20 +02:00
jaap-jan	2d95366552	Stop a reconnect dialling a different machine of the same name ... A tab remembered what its host was called and nothing else, and the reconnect under a stopped tab looked the host up by that name: HostFor took the first row in the keychain whose label matched. Nothing in this application stops two hosts being called the same thing — a team's vault beside a personal one makes it ordinary, and "prod-db" is what the database server gets called in both — so the button dialled whichever namesake sat earliest in the list. A dropped session on one machine came back as a live shell on another, with the tab, the address and the status bar all still naming the first. There was nothing on screen to read the substitution off. The name match was not an oversight; it was an argument, written into the remark on HostFor and repeated on RefreshConnectedHosts: a tab outlives the vault that opened it, so it "cannot hold an entity id that would still mean anything after a lock". That is not so. EntityId is the item's own sync identity rather than a reference to a row object, so a vault that is locked and opened again rebuilds every row around the same ids. The one handle that was rejected as too fragile to survive a lock is the handle that survives it. So the id now travels with the connection. ConnectionAttemptEventArgs and TerminalSessionEventArgs carry it, taken from ConnectionTarget.HostId, which the connect path has had all along for the log; TerminalTabViewModel keeps it; and HostFor matches on it. A host renamed since the tab opened is found too, which a name match by definition cannot. Null is not missing data — it is the whole of what makes a typed-in address different, and it is why such a tab is refused a reconnect rather than offered one that would dial a stranger sharing its name. Three other lookups had grown their own copy of the same match and so had the same fault, where it is read rather than dialled: the green connected dot, which lit on every machine answering to the name and claimed a shell on hosts nobody had connected to; the pinned paths QUICK ACCESS offers, which come from whichever row that same match found; and the sidebar's "Pin folder" and the SFTP tab row, which would have edited and browsed the wrong host. All four now go through HostFor, so "which machine is this tab" has one answer. Both new tests assert on the address actually dialled rather than on anything the tab says about itself. The two rows agree on every string a tab carries, which is exactly why this went unnoticed: a test written against the label would have passed on the day the wrong machine was being opened.	2026-09-14 10:18:58 +02:00
laurensandClaude Opus 5	fd92b80d4f	Find out why a connection did not reach, instead of only saying it timed out ... Measured against SSH.NET 2026.0.0 before anything was written, because the premise needed checking. Four ways of failing to reach a host, and what this client puts in front of the user for each: server accepts TCP, never sends a banner -> "Connection has timed out." packets black-holed, nothing comes back -> "Connection has timed out." nothing listening on the port -> "...actively refused it." name does not resolve -> "No such host is known." The first two are the same five words and are not the same problem. One is a network, a firewall or a wrong address; the other is a machine that is up and well and an sshd that is wedged, or a port that is not SSH at all. Nothing in the exception tells them apart, and that sentence was the whole of what this product could say about the failure people hit most. ◆ A SOCKET ANSWERS IT, IN ABOUT AS LONG AS IT TAKES TO OPEN ONE. SshReachabilityProbe resolves the name and opens a bare TCP connection, and the four answers it can come back with are the four somebody would do something different about — unresolved, refused, silent, open. Every one of them is what a socket actually did, measured at the moment it was asked, rather than anything inferred from the exception that started it. Deliberately nothing else. No ping: ICMP is filtered on most of the networks this is pointed at, so an unanswered one would be evidence of nothing. No scan of neighbouring ports — the question is what happened to the connection the user asked for, and probing ports nobody asked about is how a client gets flagged by an intrusion detector on the very network somebody is trying to work on. No second SSH handshake against a server that has already failed one. The budget is six seconds and the floor under it is not a guess: a refusal is not immediate on Windows, and a closed loopback port took ~2s to answer when this was measured, because the stack retries the SYN first. At two seconds the probe calls a machine that is up and refusing a firewall. The test for that case runs at the real budget on purpose, so lowering the number fails it. ◆ ONLY WHILE REACHING, AND THE WINDOW IS CLOSED AT BOTH ENDS. Past SshConnectionPhase.Reaching the machine has offered a host key, so it has demonstrably been reached and a refused password is not a reachability question. Before it, nothing has been dialled at all — a private key that will not parse throws out of BuildConnectionInfo before the factory reports anything — and probing there finds a healthy port and appends "the SSH handshake is what did not finish" to a message about an unreadable key. That is a confident wrong answer replacing an accurate one, so both ends are shut. PhaseReporter keeps the furthest phase to decide it. The finding is added to what SSH.NET said rather than replacing it: the exception is the fact, and this is a reading of a second measurement. Every shell in ShellFlowTests now gets a scripted probe. Without one a failed connection in any test in that file would do a live DNS lookup for db.internal and open a real socket — slow, network-dependent, and worse than either, since db.internal resolves on any machine whose resolver has a search domain that makes it, which would make the asserted sentence depend on whose network the suite ran from. ◆ WHAT THIS DOES NOT FIX, FOUND WHILE READING THE SAME PATH. - SshConnectionRequest.ConnectTimeout is documented, plumbed, and passed by nothing. Every connection this client makes is hard-wired to the 15-second default, and there is no per-host field and no setting that can change it. Fifteen seconds bounds the handshake waits as well as the connect — a server that accepts TCP and never sends a banner fails at exactly the timeout, measured — where OpenSSH's own ConnectTimeout covers only the connect. If timeouts are frequent on slow links, this is the first suspect, and it needs a product decision rather than a patch. - The known-host lookup in HostKeyGate.OnHostKeyReceived blocks SSH.NET's message thread inside that same 15-second budget. The blocking is acknowledged in the code; that it competes with the key exchange's own timeout is not. On a cold or locked vault a slow read would surface as a connection timeout, which is exactly the symptom above. - ConnectThroughHostKeyGateAsync never unsubscribes HostKeyReceived on success, so the gate outlives the handshake holding the connect-time CancellationToken. If SSH.NET raises that event again on rekey it would re-enter the blocking store read with a token whose source is long gone. Not verified either way — it needs a real sshd and a forced rekey. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 16:05:12 +02:00
laurensandClaude Opus 5	dabc691c35	Keep the doorbell listening between callers, and stop a hung test taking CI with it ... The test step ran for twenty minutes and had to be stopped by hand. Eighteen suites had passed; DodoSSH.Client.App.Tests never reported. ◆ ON UNIX, A FRESH SERVER PER CONNECTION LOSES THE NEXT ONE. The doorbell's accept loop built a NamedPipeServerStream inside the loop, served one caller and disposed it. That is fine on Windows and quietly wrong on Linux, where a named pipe is a Unix domain socket: disposing the server closes the *listening* socket and unlinks its path, so a second launch that connected while the first was being served has its connection dropped. Its Connect returned, its write succeeded into a buffer, and nobody ever read it — the launch was told it had rung the doorbell and the window never came forward. Reproduced in a container rather than reasoned about, because the two platforms disagree and this machine is only one of them. Three rings back to back: one instance, Disconnect between callers -> 3 of 3 answered a fresh instance per connection -> 1 of 3 answered So there is one server for the life of the doorbell now, Disconnect()ed between conversations, and the socket is never not listening. Which makes leaveOpen on the reader load-bearing too: a StreamReader disposes the stream it was given, and that stream now has to survive into the next iteration. Two things I had wrong about this, both worth recording. Cancelling WaitForConnectionAsync *does* unblock a pending accept on Linux — that was my first theory and the container disproved it, so DisposeAsync awaiting the loop was never the problem. And the app itself never hung: the lost ring is a launch that is ignored, not a process that stops. ◆ AND THE REASON IT COST TWENTY MINUTES RATHER THAN TWENTY SECONDS. await twice.Task.WaitAsync(TestContext.Current.CancellationToken); That token carries no timeout. A ring that never arrives is then not a failing test, it is a job that sits there — which is exactly what happened, and it is the more expensive of the two mistakes because it turns any future bug of this shape into a runner somebody has to go and stop. Both awaits are bounded now. TheDoorbellAnswersMoreThanOnce keeps its shape deliberately: two rings back to back rather than one and a pause, because the gap between accepts is the whole defect. A test that waited for the first to be answered would pass against the broken version. ci.yml had no timeout-minutes anywhere, on any job. Every job has a ceiling now, and the test step has a tighter one of its own — ten minutes against a suite that takes two — because a hang there is the likeliest of the lot and a step-level timeout names the step instead of leaving a reader to work out which of fifteen was still running. None of them is a performance budget; a build that legitimately grows past one should have the number raised. Verified both ways on Linux, in a container, against the committed tree and this one: 31c836f SingleInstanceTests -> hung in TheDoorbellAnswersMoreThanOnce, still going when killed at 3 minutes this SingleInstanceTests -> 7 of 7 in 1.3s this the whole suite -> 570 tests, 0 failed, 88s And on Windows, where none of this was ever broken: 570 tests, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 15:42:41 +02:00
laurensandClaude Opus 5	b8c94ecb73	Put a window on screen while it starts, and refuse the second one ... Two things a desktop application is expected to do and this one did not. ◆ THREE SECONDS OF NOTHING. Measured on a debug build against a cold profile: the main window arrives 3.1 seconds after the executable does. Nothing was on screen for any of it — the icon had been double-clicked and the desktop looked unchanged. The main window cannot come sooner. It needs a view model, and the view model needs composition to have opened the SQLite cache, bound the terminal's loopback socket, asked the platform about a TPM and read the install layout off disk. Its own IsStarting card already narrates what happens after it appears; this is the part before, which no arrangement of that window can cover. So SplashWindow, and it is measurably the point: 668 ms to the splash, 3.1 s to the window that replaces it. Two mechanics are load-bearing rather than incidental. The splash *is* desktop.MainWindow for a moment. The lifetime shows whatever that property holds once OnFrameworkInitializationCompleted returns; a window merely Show()n there would have no lifetime attached, and under ShutdownMode.OnLastWindowClose the first close of anything would end the process. Handing the property over is one assignment and Avalonia reads it lazily. And composition is posted at DispatcherPriority.Background rather than called. It is synchronous and slow — which is the entire argument for a splash — so running it inline would block the very dispatcher turn that has to paint the thing. The window is SizeToContent="Height", which is about the failure and not the splash: CouldNotStart carries an exception's own message, and inside a fixed height a long one would wrap and be clipped at exactly the moment that text is all the window is for. A composition that throws is caught rather than left to the dispatcher, for the same reason — before this there was nothing on screen to abandon, and now there is, so an escaping exception would leave a window saying "Starting…" over a process that had stopped. Escape closes it, and only then. ◆ AND ONE INSTANCE. Claimed in Main before Avalonia is configured, so a second launch starts nothing at all: no toolkit, no window, no splash flashing up before it thinks better of it. Exclusion is an exclusive handle on instance.lock inside the profile directory, and that location settles two questions at once. A nightly and a release build do not exclude each other — separate profiles, ADR 0013 — and two people signed in to one machine each get their own instance. A global mutex would have had to re-derive both from somewhere. A file handle rather than a named mutex because the kernel releases it however the process ends. There is no such thing as a stale lock here, which is a state a named mutex makes both platforms model differently and neither model simply. The second launch is not silent. Somebody who double-clicks an icon and sees nothing has been told the application is broken, so it rings a named pipe — named from a digest of the profile path, so it is scoped exactly as the lock is — and the running instance un-minimises and activates. Activate is a request and not a guarantee: Windows refuses the foreground to a process that did not receive the input, and the flashing taskbar button that results is still an answer. Three seconds of retrying when the lock is held by something that does not answer its pipe, and that window has one job. Velopack's apply ends this process and its updater starts the new build; the two are ordered, but a lock held a moment too long would make the successor refuse itself and vanish — an update that looked like an uninstall. The doorbell is disposed before Shutdown for the same reason, so the pipe name is free before the process is. ◆ VERIFIED BY RUNNING IT, WHICH IS THE ONLY WAY EITHER OF THESE COULD BE. Two launches of the built executable: the first stayed up with instance.lock in the profile, the second exited. Window sizes over time are where the two timings above come from — 420x160 then 1196x776. SingleInstanceTests covers what a single process can reach: the lock, its release by disposal, the doorbell answering more than once, and two profiles not excluding each other. SplashCardTests measures the one thing the splash can get wrong, which is a failure message long enough to need the height the window is willing to give it. Checks 1.12 and 16.11 are what needs a second executable and a real screen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 14:49:15 +02:00
jaap-jan	c859705b83	Give the hosts board its vaults, and the Hetzner import a vault and a key ... Six things, all of them answers to a question a screen was deciding on somebody's behalf. The board draws a heading per vault and sorts each vault's hosts by that vault's own groups. A group is an item of one vault, so drawing every group of every vault in one run flattened away containment that already exists: two vaults each holding a "production" were two headings with the same word on them, told apart by a small grey name beside each. Single- vault sessions are unchanged. There is now one "No group" heading per vault, so the folded set is keyed on SidebarGroupHeader.CollapseKey rather than on GroupId ?? Guid.Empty, which had one vault's unfiled hosts folding every other vault's away with them. A Ctrl-click starts its set with the card the board has lit. The board always has a selection — a fresh unlock lights the first host so CONNECT has something under it — so "one card lit, nothing ticked" is the state this screen opens in, and ticking a second card there produced a set of one: the machine the user was looking at was left out of the count and out of everything Delete, Move and Change group then ran over. The card tooltip says the host's name as well as its address. 214 pixels of card trims the name, and the tooltip was the one place it was not said in full. The card's floor drops from 120 to 104. A card with no tags measures about 87, so the mock's number was thirty pixels of air under every card on a board that is scrolled. "Move to another vault…" joins the board's context menu for one host. Moving one machine meant opening its pane and finding the menu inside it, while moving six was a right click away — the one-host case was the harder of the two. And the Hetzner import asks which vault and which key. A project belongs to a team more often than to a person, so forty servers landing wherever the session happens to be standing is the wrong default; ImportHostsAsync takes the target vault, and the ssh_config importer passes null and is unchanged. The key is the half Hetzner cannot supply and the keychain usually already holds — the public half went to Hetzner when the servers were made — so the import points every host at it rather than bringing one. It defaults to no key rather than guessing, and says so when the key it was given lives in a different vault from the hosts.	2026-08-26 11:54:29 +02:00
jaap-janandClaude Opus 5	c270f3fe39	Import a Hetzner Cloud project's servers, and forget the token that read it ... An estate on Hetzner is already described somewhere: the project lists every server, its addresses, its plan and where it runs. Getting that into a keychain meant copying forty addresses out of a browser by hand, which is the same work the ssh_config importer exists to remove for the machines described in a file. ◆ A WIZARD RATHER THAN A SCREEN, AND THE DIFFERENCE IS WHAT EACH STEP COSTS. ImportScreen reads a file that is already on this machine, so it scans on open and shows a list. This cannot: it needs a credential that has to be made in another company's console first, and then it makes a request over the internet. Those are two moments rather than one, and a screen that mixed the token box in with the list would ask for the credential again every time somebody came back to look at the list. So three steps — token, choose, done — and the first two write nothing. Step two carries one address choice, one login user and one port for the whole import, because an estate is reached the same way throughout and a per-server dropdown would be forty answers to one question. ◆ THE TOKEN IS USED ONCE AND CLEARED, INCLUDING WHEN IT WORKED. The half worth stating is the success path. Clearing only on failure would leave a credential capable of listing somebody's whole estate sitting in a text box for as long as they spend reading forty rows, which is the longest anybody stands on this screen. Nothing writes it to the vault, to settings or to a log, and reopening the wizard restarts at step one rather than resuming — a resumed step two would be a list nothing on screen has the means to refresh, going on looking current for as long as the application stays open. Read is the only permission it needs and the note above the box says so: a Read & Write token would work identically here and would be a credential capable of deleting the estate, pasted in for no gain. The note also says a token belongs to one project — there is no API call that will say which, and none that lists the others — so an account with four projects runs this four times. Without that sentence the wizard looks like it lost most of the estate. ◆ THE ADDRESS IS A CHOICE, AND TWO OF THE THREE FALL BACK WHERE THE THIRD MUST NOT. Public IPv4 and public IPv6 fall back to each other: the same machine over the same internet, so the worst case is a route nobody picked, and the row says which. Private does not fall back at all. A server on no private network is simply not importable under that choice — its tickbox is disabled, and neither direction of the header's tick-all can reach it — because falling back would put an address on the open internet into a bookmark that was asked to stay off it. IPv6 needs saying twice over. Hetzner routes a whole /64 and the API reports the network, which nothing can dial; the address a stock image answers on is the first one in it. That is a convention of Hetzner's own images rather than a fact the API stated, so every use of it carries a warning on the row and in the stored note, and it is computed by setting the low byte rather than by string surgery on the prefix. It is not an edge case either — IPv4 is billed separately now and a project built since then can be entirely IPv6-only. ◆ NOTHING IMPORTED HERE AUTHENTICATES, AND THAT IS SAID BEFORE THE BUTTON. Hetzner has never held the private half of an SSH key. The API will name a project's keys and hand over their public halves; there is no private half to bring. So every host arrives bound to nothing and asks for a password until somebody points it at a key already in the keychain — the same shape an ssh_config import has with its key tick off, and stated above the button on the same reasoning: somebody who is not told will conclude the import was broken. What the note keeps is what does not go stale — the id, the plan, the location, the image, the labels. The power state is a column and never a note: "running" about a machine somebody switched off last March is worse than no note. ◆ WHERE IT LIVES: TWO FLAGS OVER ONE CONTENT COLUMN. Drawn over the Preferences page inside settings mode exactly as ImportScreen is, with SettingsNav unmoved and the titlebar offering "Back to preferences". IsHetznerImportOpen is a second flag rather than a "which importer" enum, because they are two independent facts about the content column and a single value would need a "neither" member IsImportOpen already expresses; what keeps them from both being true is that every path that opens one closes the other. The titlebar and the Preferences page ask IsImporterOpen, which is written against both. Preferences grows a second importer row beside the first rather than one row that asks "from where?", which would put a question in front of the far more common answer. ◆ WHAT IS NOT HERE. Hetzner's Robot — dedicated servers and Storage Boxes — is a different API behind a different credential, and nothing in this touches it. Said on the Preferences row and on the token step rather than left to be discovered by an account that has both. And there is no phone layout. This one would work on Android, unlike the ssh_config importer beside it: it is a token and a network request, the view model is shared already, and scoped storage has nothing to do with it. What is missing is a screen — the desktop draws a five-column table, and the phone version of that is a different layout rather than the same one narrower. Recorded in android-port.md and on the phone's own Preferences screen, because the note there previously read as though no import of any kind could work. ◆ TESTS, AND WHAT IS LEFT FOR A PERSON. HetznerCloudClientTests is 16 cases over the shapes the API actually returns, against a stubbed HttpMessageHandler: paging followed, the token in a header and never a query string, a refused token distinguished from a fault at Hetzner's end, a token with a line break refused before anything is sent, the /64, the private-network asymmetry, and a server the API described without a name. ShellFlowTests.Hetzner.cs is 11 more against this fixture's real vault, real cache and real server — split into a file of its own, as FakeVaultServer keeps its team endpoints. What they establish beyond the reader's own suite is the half it cannot reach: that reading stores nothing, that importing goes through the ordinary create-and-push path and lands on the server with nothing pressing Sync, that a server the keychain already has arrives unticked, and that the token does not outlive the request. Two layout cases measure both steps against the same content budget every other settings page gets, which is also what proves the markup binds to names that exist. Manual checks 2.11a–2.11d are what no test in this repository can do, because there is no account, no token and no network in the ordinary suite: a real project listed against the real console, a wrong token, the private choice, and what an imported host does when you connect to it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 10:51:11 +02:00
laurensandClaude Opus 5	56c19b006d	Stop the updater offering the build it saw first, whatever has been published since ... A client two versions behind was offered the older of the two, installed it, restarted, and was told at once that another update was waiting. Two downloads, two installs and two restarts to move one step. The feed was not the problem and could not have been. The nightly release is deleted and remade on every push to main, so it holds exactly one build: a client can only ever be offered the newest thing there is. The wrong version came from this application's own state. ◆ THE PASS STOPPED ASKING, WHICH IS NOT WHAT IT WAS MEANT TO STOP DOING. if (!IsAutomatic || State is UpdateState.Downloading or UpdateState.Ready) Ready means something is downloaded and waiting. The intent behind excluding it is right — there is no point fetching what has already been fetched — and what it actually did was skip the check. So from the first thing any process downloaded, its banner was pinned to that build for the rest of its life, however many newer ones were published afterwards. On a rolling channel that is the normal case rather than a corner. Not re-fetching is still the rule and now lives in FetchAsync, which compares versions rather than refusing to look: the same build is left alone, a newer one replaces what was pending. Which is also why FetchAsync answers with what is *pending* rather than with what the check returned — a client on 1.0 holding 1.1 is told 1.1 by every later check, because 1.1 is still the newest thing on the feed, so "the check found something" and "there is something new" are different questions and only the second one is worth a download. A build already fetched is never discarded, including when a check answers null. Null means the feed's newest is no newer than the build that is *running*, which says nothing about the one on disk — that one is still newer, and withdrawing an offer somebody has already been shown would be the worse answer. ◆ AND A LAST LOOK BEFORE THE PROCESS IS REPLACED, WHICH IS THE HALF THE TIMER CANNOT REACH. The loop asks every six hours. The build that caused this was published minutes before RESTART NOW was pressed, so no interval anybody would accept would have caught it. The press now asks once more. It costs one small request in the ordinary case, because the feed answers with the build already on disk and nothing is fetched. It costs a download only when there genuinely is something newer, which is the case where the alternative was two downloads anyway. Bounded at ten seconds, and the wait rather than the request: VelopackUpdateChannel records that Velopack's check takes no token, so cancelling would be observed only after the call had already returned. Ten seconds bounds a small JSON document against a network that drops packets rather than refusing them; a refused connection fails in milliseconds and never reaches it. Nothing here refuses a restart. An unreachable forge, a look that ran out of time, a fetch of the newer build that failed halfway — all leave the build on disk untouched and still newer than the one running, so the restart goes ahead with it. Hence swallowed rather than reported: Failed is for something a person is waiting on an answer to, and this person is waiting on a restart they are about to get. IsRestarting keeps the banner up through it. Everything the strip draws keys off IsReady and the look moves the state off that, so without it pressing RESTART NOW made the banner vanish with nothing on screen saying why, for as long as a 120 MB package takes. It says what it is doing instead, percentage and all. ◆ THE CHANNEL HAD TO LEARN WHICH BUILD IT FETCHED, AS AGAINST WHICH IT LAST FOUND. Required by both halves above rather than tidied along with them. Matched() resolved an AvailableUpdate only against `found`, which a check overwrites — and both changes make this application check while a build is already downloaded. A check that lands a newer answer and then fails to fetch it, or is given up on halfway, leaves the shell restarting with the build it already has and Matched() throwing at it: the offer real, the package on disk real, and the only thing wrong being that the channel had forgotten which one it was. A slow forge became a refused restart. So `fetched` is recorded after a download returns, tried before `found`, and survives every later check. Settings → General claimed checks start "a couple of minutes after launch", which has been untrue since the first pass moved to launch. It now also says the loop keeps asking while an update is waiting, because that is the behaviour somebody reading that row would want to know about. UpdateFlowTests goes from 21 to 28: the pass asks again and fetches once, the pending build is replaced when the feed moves on, a superseded offer reappears through a dismissal, the press installs what the last look finds, and the three ways the last look can fail all still install what was already on disk. Check 16.7a is the manual half, needing two real releases. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 16:14:09 +02:00
laurensandClaude Opus 5	1908189100	Make the terminal's right button copy and paste, and never open a menu ... Selecting output and right-clicking it opened the WebView's own context menu with Copy on it, which is correct behaviour for a web page and wrong for a terminal. What a terminal's right button has meant since the Windows console got QuickEdit, and since PuTTY shipped, is this: with something selected it copies and drops the selection, with nothing selected it pastes. No menu, no second click. The gesture can only live in the page. The selection is drawn into a canvas the host never sees, and once a terminal has focus the host's window receives no input events at all — the same reason the Ctrl+plus chords are handled there. ◆ THE CLIPBOARD IS THE HOST'S IN BOTH DIRECTIONS, AND THE READING IS WHY. navigator.clipboard.readText() is gated behind the clipboard-read permission in every Chromium, and an embedded WebView with no PermissionRequested handler answers a permission request by putting a prompt on the screen. Trading a context menu for a permission dialog is not this change. So the page asks and the host answers, exactly as requestFontSizeStep does. Writing does not go the other way either, although navigator.clipboard.writeText would have worked from the page on Windows: a clipboard that is the host's in one direction and the page's in the other is two mechanisms to keep working across WebView2, WebKitGTK and Android's WebView. The host has owned a clipboard delegate since the keychain grew its COPY buttons, so each App.axaml.cs grows a ClipboardReader beside its ClipboardWriter and MainWindowViewModel takes it. Three opcodes: client ClipboardCopy and ClipboardPaste, server Clipboard. ◆ Clipboard IS NOT Paste, AND THE DIFFERENCE IS THE BRACKETING. Paste carries a snippet off the sidebar, and the page deliberately *types* a single-line one rather than bracketing it, because bash marks a bracketed paste as an active region and a snippet should read as though it had been typed. A clipboard paste is the case those markers are for — readline uses them to decide it has been pasted into — so Clipboard is always bracketed and never followed by an Enter. One opcode for both would have needed a flag meaning "which of the two kinds of paste is this", on a payload whose existing flag byte means something else. Both client frames are dispatched before the session lookup, which is what keeps the gesture working in a pane whose shell has just ended: squinting at the message a remote left behind is exactly when somebody copies the line. Dispatch was past MA0051's length once it grew a second such branch, so the frames no pump needs to see moved into Announce() and the font-size chord went with them. ◆ CAPTURED AND STOPPED, RATHER THAN MERELY PREVENTED. preventDefault alone suppresses the menu and still lets xterm's own contextmenu handler run, which moves its helper textarea under the pointer at z-index 1000 and leaves the selection sitting in it, selected. Both of those exist to serve the native menu. Taking the event in the capture phase on the pane and stopping it there is what keeps the gesture wholly the page's. rightClickSelectsWord is now false, which on macOS is a change of default rather than a restatement of it: xterm sets it true there alone, so a right-click would have selected the word under the pointer and copied that instead of pasting — wrong on one platform only, which is the worst way for it to be wrong. The renderer harness grows the pane it has been inviting since RendererReconnectionTests: a fake Terminal, the two addons, and a real UTF-8 codec, because both directions run through the page's own TextEncoder and TextDecoder and a Latin-1 stub would pass a test with an em dash in the selection. Its warning about declaring names terminal.js declares now covers the half that does not SyntaxError — a harness frame() was silently replaced by the page's frame() and failed six tests on a type error a long way from the cause. Manual checks 1.11 and 11.13 are what is left for a person: that a real contextmenu event reaches a capture listener, that no native menu is drawn once it is prevented, and that xterm's real paste() brackets. 11.13 also records what is unverified — whether Android's WebView delivers a pointer's secondary click as a contextmenu event at all. ClipboardReader is wired on that head regardless, because the alternative is a head where the paste half silently does nothing and nobody finds out; that head is not compiled here either, this machine having no android workload. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 14:46:36 +02:00
jaap-jan	cfc2e3ae0c	Notice when a file session stops, and give the file browser the four things it was short of ... The commit before this one taught a terminal to notice its machine going away. The file browser had the same defect and three of the same symptoms, and it is also the screen people leave soonest — so the disconnect work and four things it was missing arrive together, because they are the same complaint: this screen knows less about the host than the host does. ◆ THE DISCONNECT HALF, WHICH IS THE OTHER SURFACE OF THE LAST COMMIT. IsConnected was set at connect and cleared only by the DISCONNECT button. A host that went away therefore left this screen saying CONNECTED over a session that was gone, and every action after it failing with the same server message and nothing saying why they all did. IRemoteFileStore now carries a latched TransportFailure and a ConnectionLost event. The latch is the shell's own — read ISshShellSession.TransportFailure for the argument, which is unchanged. The event is not, and it is the part this surface needs: a file browser is idle between operations, so without something raised at the moment the transport fails, nobody finds out until they click. A bucket implements both and raises neither, which is honest rather than a gap: S3 is request-per-operation with no connection to lose. - THE LISTING STAYS ON SCREEN, and that is the half that makes the rest worth having. SftpEntry is a record of what the server said rather than a handle, so the pane can go on showing where the user was — which is what RECONNECT is offering to put them back into. That needed a new ShowsRemoteContents on both heads: every "is there anything here" binding read IsConnected, which was right while the only way to stop being connected was to press a button that empties the pane, and wrong the moment a session could be lost. - RECONNECT re-dials through the ordinary connect path — same host key gate, same refusals, same log entry — and then walks back to the directory the pane was showing. The path is read off RemotePath rather than captured, because the pane already keeps it up to date and a copy is a second thing to get wrong. A host wanting a typed password is asked for one rather than dialled with an empty box. - SessionEndedBar is now one control on both surfaces, with the shell resolving which it is drawn over: a terminal has two endings to tell apart and a keychain entry to check, a file session has one ending and already captured what it would dial. The phone's Files screen has its own copy, bound to TransfersViewModel directly, because its DataContext is that rather than the shell. ◆ PERMISSIONS: THE PERMS COLUMN STOPS BEING READ-ONLY. It has been a true fact about a file with nothing to be done about it since it arrived, and the commonest next act after using this screen was opening a terminal — a whole second authenticated connection — to chmod what had just been uploaded. Nine checkboxes rather than a box to type 755 into, because the mode is already drawn as -rwxr-xr-x in the column the form was opened from: a who-can-do-what grid is the same representation the reader is holding, where an octal field asks them to translate something they can see into something they cannot check. The octal is printed underneath as it changes, so the two readings check each other. The EXEC column is headed "enter" over a directory, which is what that bit means there and the commonest misreading of a POSIX mode. The listing is re-read after APPLY, because a umask, an ACL or a filesystem mounted without permissions can all land somewhere other than what was asked for. Beside it, mode and mtime carried across a transfer — which is what makes an uploaded deploy.sh arrive executable instead of with the server's umask on it. THE MODE IS ONLY SENT FROM A PLATFORM THAT HAS ONE. A file on Windows has no POSIX mode; this screen already says so by leaving the local pane's PERMS column empty rather than filling it with a plausible -rw-r--r--, and inventing 0644, or 0755 for anything called .sh, would be this client deciding a fact about somebody's file that nothing on the machine it came from ever said. The timestamp goes either way, because every platform has one. A store with neither refuses in its own words and is never asked. ◆ MULTI-SELECT: A TICK IS NOT THE LIST'S SELECTION. The two answer different questions and the split is the whole design. The selection is "the row I am looking at", which rename, move and permissions act on — each takes a form naming one path and is one-at-a-time by construction. The tick is "the rows I have gathered up", which download, upload and delete take, and it survives the highlight moving. With nothing ticked the batch falls back to the selection, which is what keeps the commonest use of this screen from growing a step — the usual way a multi-select makes a tool worse. Ticks are released once a set is queued, or a second press sends everything again. Deleting several names every path rather than a count, because agreeing to "3 items" is agreeing to a number, and this is the one act on this screen that nothing walks back. Each goes on its own and a refusal does not stop the rest: the host turns down a directory that still has something in it, and in a set of five that must not silently cancel the four it would have removed — nor hide which ones it did not. A drawn checkbox rather than ctrl-click, and not for taste: the phone shares this view model and has neither ctrl nor shift, so a multi-selection has to be a tap target there whatever the desktop does. One shape on both heads, and a state somebody can see. ◆ RECURSIVE FOLDERS: THE TREE BECOMES FILES BEFORE THE QUEUE SEES IT. A directory used to be counted and skipped. It is now walked, and the queue still knows nothing about trees — which is what keeps every property it has: each file resumable on its own, each written to a part file and renamed into place, none able to overwrite anything already there. The plan is collected whole and then queued, because directories have to exist before the files that go in them and shortest-first is the only order that guarantees a parent before its child. It also means a walk refused halfway has queued nothing yet, so the sentence it produces describes one outcome rather than an outcome and a queue that half happened. Links are counted, not followed, in both directions. One pointing at an ancestor is a walk with no end, and on the remote side there is a second reason: an lstat listing says a name is a link and not what it leads to, so descending would be a round trip per entry to find out. Locally that is AttributesToSkip on the one enumeration that decides what to descend into. A 5000-file ceiling is a backstop for the accidental drag of a home directory, and it says so rather than truncating quietly. The status line grew four more ways to be partly what was asked for, and states each: gone, refused, left alone, not a file. ◆ EDITING IN PLACE: FETCH, OPEN, WATCH, PUSH BACK. The round trip this replaces is download, find it, open it, edit, come back, delete the old one because nothing here overwrites, upload, check the mode survived. DELIBERATELY NOT THROUGH THE TRANSFER QUEUE, in either direction. The queue refuses to overwrite, which is the right rule for a file somebody dragged and exactly the wrong one for a file they are editing, where replacing the original is the entire intent. The write-back deletes first: OpenWriteAsync at offset zero writes over the beginning and leaves any tail that is longer — its own contract says so — which for a config that got shorter means a file ending in the back half of its previous version. Deleting is the only truncation this interface offers, and the mode goes back on afterwards because deleting took it. A stat before every save, compared against what the server said when the copy was taken, catches somebody else writing while the file is open — which is how a config gets silently reverted. There is no merge and no button pretending otherwise; the three answers offered are the three that exist. Length and timestamp rather than a digest, because a digest is a second full read of a file there is otherwise no reason to fetch. Both platform halves are injected: what opens a .conf is a registry association, a desktop entry or a Launch Services binding depending on the desktop, and watching a file is a platform object with its own thread. The watcher watches the directory and filters the name, because a great many editors write a temporary file and rename it over the top — which to a watcher pointed at an inode is the file disappearing. The phone gets neither delegate, so the button is not live there rather than there and disappointing. ◆ TWO THINGS FOUND ON THE WAY, BOTH WORTH STATING. The shell suite's inline `post` was not serialising the way a dispatcher does. Routing TransfersViewModel through it exposed a check-then-add in OnTransferChanged that two threads turn into two rows for one transfer. Harmless in production, where the UI thread serialises — the fixture was under-specifying what it stood in for, and now posts under a lock. And the edit session replaced its own record with `with` on each save, which left the watcher holding an instance that was no longer the current one: every save after the first quietly did nothing. The stamp moves in place now, and the test saves twice. ◆ WHAT IS VERIFIED. 901 across the five suites this touches, 19 of them new. The layout suite earned its keep three times over: the batch deletion card's path list overflowed the 204-pixel pane at 120, at 72 and at 56 before 32 held, and the edit strip overflowed by 131 until the whole strip — rather than the log inside it — was bounded. Each number in those files is measured and says which failure it came from, because the next person to add a line to either card will move them again. What no suite covers is the platform halves of editing: Process.Start with UseShellExecute and a live FileSystemWatcher are the operating system, and a test waiting on one would be measuring it. The shell's own half — when a save is written back, when it is refused, what stopping releases — is covered against a watcher that fires on demand.	2026-08-24 11:48:23 +02:00
jaap-jan	e2733e5cbc	Notice when a shell ends, say which way it ended, and offer the way back ... A terminal whose machine rebooted stayed green for ever. Not "went stale and recovered late" — for ever: the tab claimed CONNECTED, the elapsed timer went on counting, and the only thing that ever corrected it was closing the application. That is the defect this fixes, and it turned out to be two separate failures wearing one symptom. ◆ THE HANG IS IN SSH.NET, AND KEEP-ALIVE ALONE WOULD NOT HAVE FIXED IT. ShellStream ends a blocked read from exactly two places: its channel being closed, and the session raising Disconnected. A shell that exits gives the first. But Session raises Disconnected from one method only — OnDisconnectReceived, for a server that politely says goodbye — and a socket that simply fails goes down a different path entirely: RaiseError fires the error event, sets the disconnecting flag and disposes the socket, without ever raising Disconnected. So the stream was never disposed, its Monitor.Wait was never pulsed, and the read blocked until the process ended. The transport was gone, the client knew the transport was gone, and nothing woke the one thread that was waiting. That is why the first attempt at a test for this sat at thirty seconds and failed. Both halves are needed and neither is sufficient: - Keep-alive makes the failure HAPPEN. An idle SSH session is a socket nobody writes to, and TCP has no way to discover that the far end has gone without writing to it — nothing was asked, so nothing could fail. Thirty seconds, matching OpenSSH's own ServerAliveInterval examples. It is the write that matters and not a reply: SSH_MSG_IGNORE need not be answered, so this is traffic rather than a heartbeat with a deadline, and there is no timeout invented here to be wrong about a slow link. - Disposing the stream from the error handler makes it ARRIVE. Queued to the thread pool and not done inline, which is not tidiness: this runs on SSH.NET's message-listener thread, and closing a channel waits for the server's close — processed by that same thread — so an inline dispose is the listener thread waiting on itself. SFTP gets the keep-alive too. Its operations are request/response and bounded by ConnectionInfo.Timeout already, so it needs no equivalent wake-up. ◆ exit AND reboot ARE TOLD APART BY A LATCH, BECAUSE THE OBVIOUS WAY IS A RACE. Wait for the read to end and then ask whether the transport is still up, and against a real server the answer is wrong about half the time: this was the only channel on the connection, so sshd hangs up a millisecond after closing it. By the time anything could ask, the transport is gone either way — and a poll would report every ordinary `exit` as a dropped connection. So ISshShellSession.TransportFailure is set at the moment SSH.NET raises the failure, which its own ordering puts strictly before the disconnect that wakes the read. A read that has just returned zero consults a settled value: set if the transport failed, still null if the remote merely closed the channel. The pump turns that into a TerminalSessionOutcome — RemoteClosed, ConnectionLost, ClosedLocally — carried on SessionEnded, which used to hand over a session id and nothing else. A subscriber cannot work this out afterwards; by the time it hears, there is no transport left to interrogate. Deliberately no fourth value for "the remote rebooted". Nothing on the wire distinguishes a reboot from a cable being pulled, and a name this client cannot check would be a guess dressed as a fact. ◆ WHAT IS DRAWN, AND WHY IT IS NOT DRAWN OVER THE PANE. The status bar says DISCONNECTED or SHELL EXITED where it used to say NOT CONNECTED for both — a word that is honest about a tab still dialling and useless about one whose shell has stopped. Red for the first and grey for the second: one is a machine that stopped answering and the other is work finished, and crying wolf on the ordinary end of every session is its own bug. The tab strip's dot gains the same fourth state, on both heads. Under the terminal, a strip carrying the reason and two buttons. It takes its own Auto grid row rather than overlaying the renderer, and that is forced rather than chosen: the WebView is a native child view composited above everything Avalonia draws, so the alternative is collapsing the terminal — and the scrollback is precisely what the user wants to read, because the last thing the remote said is usually why it went. terminal.js already writes the same sentence into the pane; this is the copy that does not scroll away. RECONNECT reuses the tab in place, which is what the word means to somebody who pressed it: the terminal they were working in comes back, where it was. It dials through the vault's ordinary connect path, so every refusal — a key that has left the keychain, an unknown host key, a group default that has changed since — is decided in the one place that already decides them; what this adds is which tab the attempt belongs to. The old session is closed as part of it, because a dead shell still holds an authenticated connection this process has stopped reading, and its pane still holds an xterm, a scrollback and a WebGL context, of which a browser hands out about sixteen. Two refusals it makes rather than pretending: a host reached by typing an address has no keychain entry to redial, and one that wants a password typed goes to the keychain with the sheet raised rather than being dialled with an empty box. Both say so on the strip where the button was pressed, not only in the vault's status on a screen that surface is not. TRY AGAIN appears on a refused connection for the same reason, and it is worth as much: the commonest refusal is a host that was not up yet. ◆ WHAT IS ACTUALLY VERIFIED. Two tests against a real sshd in a container. `exit` is reported as the remote closing the session — the one a polling implementation fails, and a fake shell cannot show it because a fake has no server behind it deciding to hang up. And a live shell losing its transport is reported as a lost connection, produced by dialling through a plain TCP relay the test owns and then cutting it; the container is shared by the collection, so killing sshd was never an option. The first draft of that second test used LoopbackProxyTests' SOCKS forward and timed out: disconnecting the carrier of a ForwardedPortDynamic does not close the loopback socket it accepted. Recorded in the test, because it is a property of SSH.NET's forwarder rather than of anything here, and it is not what a dying machine looks like. What no test reproduces is the waiting. A relay that closes sends a FIN, so the socket reports itself at once; a machine switched off sends nothing, and finding that out is the keep-alive's business and the OS's retransmit budget's — neither of which a test can hurry along without a clock this code does not own. A reboot is prompt in practice because the machine comes back and RSTs. Beside those: three pump outcomes, three workspace announcements, and seven shell-flow tests covering the drop, the clean exit, reuse of the tab, retry after a refusal, and both ways a reconnect can honestly come to nothing. Also fixed in passing: SshNetShellSession.IsOpen read ShellStream.CanRead, which is documented as always true — the stream stays readable after disposal so buffered output can be drained — so it had answered "yes" for every shell that ever existed. It reads CanWrite now. And MainWindowViewModel's session- ended handler moved from Dispatcher.UIThread.Post to the injected post delegate, which is what makes any of the shell half testable at all; the remark listing the three unreachable posts is one shorter.	2026-08-24 10:36:15 +02:00
jaap-jan	c2c860b4f2	Give the seated user the TPM, so nobody has to join the tss group ... ADR 0007 decision 4 refused this a commit ago, on the grounds that widening access to the machine's TPM is a system-wide decision an application package should not make for an administrator. That refusal is overturned here, and the reasoning it is replaced with is narrower rather than louder — because the refusal had treated "widen access" as one thing when it is two. Adding a person to `tss` is what the refusal was really about, and it stays the wrong answer: permanent, effective over SSH, applying whether or not they are at the keyboard, and needing an administrator and a fresh login before the feature appears at all. Tagging /dev/tpmrm0 with `uaccess` is a different thing. It is systemd's own mechanism for this exact question — the one /dev/dri, webcams, scanners and FIDO keys already use — and logind grants the ACL to the user of the *active local session*, then takes it back when that session ends. Not over SSH, not on an inactive VT, not to daemons. The rule changes neither the mode nor the group, so everything that worked before still works and the ACL is layered on top. tpmrm and never tpm, which is what makes it defensible at all: /dev/tpm0 is the raw device and is exclusive, where /dev/tpmrm0 is the kernel's resource manager, which virtualises handles and isolates callers precisely so that more than one unprivileged program can use the chip. ◆ THE COST IS A DENIAL OF SERVICE AND NOT A DISCLOSURE, AND IT IS WRITTEN DOWN. TPM objects are protected by their own auth values, so this lets nobody read anybody else's sealed data. What it allows is *failed* attempts — and a TPM answers enough of those by locking out everyone, which is the same anti-hammering this project relies on to make a four-digit PIN safe. On a machine that unlocks its disk with the TPM at boot, somebody sitting at it can trip that and stop the next boot from unlocking until it recovers. An administrator who does not accept that masks the file: sudo ln -s /dev/null /etc/udev/rules.d/71-dodossh-tpm.rules which is the standard override, survives upgrades, and puts DodoSSH back to behaving as though the machine had no TPM. That is in the rule's own comments, because the person who needs it is reading the file rather than the ADR. Numbered 71 because 60-tpm-udev.rules is what creates the node's ownership and 73-seat-late.rules is what turns the tag into an ACL; verified in that order on Fedora 44, along with `udevadm verify` accepting the file and the mask being reported as "masked by previous entry". %post reloads and replays it against the tpmrm subsystem, because a rule that waits for a reboot is a feature that does not work on the day it is installed. Both channels install the same path deliberately: this is about the machine's TPM rather than about either build, the file is byte-identical from both, and giving each its own copy would mean removing one package silently revoked the other's access. Phase 19 grew a check that the ACL exists for the local session and does *not* exist for an SSH one, and another that masking the rule really does put the machine back — then tells you to undo it before the checks that follow. Also recorded, after it cost five confusing failures: swtpm serves exactly one client, so a shell readiness probe sitting on the port makes the whole device-key suite fail with "The TPM closed the connection" and nothing pointing at why.	2026-08-22 20:38:22 +02:00
jaap-jan	4552538533	Let the Linux head check for updates, and seal its device key in the TPM ... Two things the RPM shipped without, and the reason they arrive together is that both are the same question — what may this platform ask of the machine, and what must it not ask of the user. ◆ UPDATES: THIS CLIENT CHECKS AND FETCHES, AND PACKAGEKIT INSTALLS. ADR 0013 rule 11 said there was no updater at all, and that went too far. It conflated noticing that a newer build exists with installing it: the second is what the trust argument is about, and the first is not — a client that checks a fixed address and tells you what it found has taken no capability from anybody. Written as a flat refusal, the rule bought its safety by paying a cost that was avoidable, and the ADR now says so in its own words. So LinuxUpdateChannel reads the rolling nightly release, compares versions the way rpm compares them, downloads the package, verifies its digest and hands the file to PackageKit over gdbus. Polkit asks; the user may say no; nothing is torn down before the answer, because ApplyingEndsTheProcess is false and the shell already knows what that means — it is the phone's shape, and declining an update must not cost somebody their open shells. Three details that are load-bearing rather than incidental: - The comparison is rpmvercmp and not SemVer, because rpm is what will accept or refuse the install. Same argument ADR 0014 makes for versionCode. The installed side is read out of the rpm database rather than derived from the assembly, so the SemVer-to-rpm translation exists in exactly one place. All 28 expected values in RpmVersionTests came out of rpm itself rather than out of a reading of the algorithm. - The digest is checked and is not a signature. Velopack verifies its own downloads and Android checks a signature; an RPM over HTTPS has neither. The manifest names a SHA-256 and a mismatch deletes the file rather than leaving something installable-by-hand in the profile directory. - ONLY_TRUSTED is cleared, which is what routes the request to polkit's package-install-untrusted action. The package is unsigned, so requiring trust would fail every update at the last step. ◆ THE DEVICE KEY: SEALED IN THE TPM, BEHIND A PIN THE TPM CHECKS. ADR 0007's amendment is the bar: a gate inside the process is not a gate. The key is sealed into a TPM 2.0 keyedhash object whose userAuth comes from a PIN, so unsealing is a command the chip refuses; the blob is encrypted to the storage hierarchy and is useless on any other machine; nothing here ever compares a PIN. The sealed object deliberately carries no NoDA attribute, and that one omission is the whole reason four digits is enough: every wrong answer advances the TPM's dictionary-attack counter and the chip stops answering entirely once it trips. Measured at four wrong tries against a software TPM, after which the correct PIN gets nothing either. It is asserted by a test rather than left to a reading of the template, because removing the attribute leaves every other assertion passing. This is weaker than Hello and Touch ID and the difference is invisible, so it is written down in three places rather than smoothed over: those raise their prompt from inside the platform and this one is a window we draw. The prompt is deliberately plain for that reason — teaching people that a convincing DodoSSH PIN box is a system dialog is the one thing this design must not do. Rejected, each for failing the amendment: the Secret Service API, which has no per-use consent and is DPAPI's shape exactly; fprintd, which answers a question and holds nothing, so skipping the call skips the gate; and a polkit-gated root helper, which would work and puts a privileged component in a package that installs nothing setuid. Availability is narrower than "has a TPM": on Fedora /dev/tpmrm0 is root:tss and desktop users are not in tss, so the ordinary case reports unavailable and keeps asking for the passphrase. Shipping a udev rule to widen that is refused — it is the administrator's decision, not an application package's. ◆ WHAT IS ACTUALLY VERIFIED, SINCE THAT IS THE PART THAT USUALLY ISN'T. This is the only device key store in the repository with real coverage, and it is only possible because the PIN is a delegate and the TPM is a device: seal, unseal, wrong PIN, lockout, decline and a foreign blob all run unattended against a software TPM. Windows and macOS cannot be tested at all — their prompts block a suite forever, which WindowsDeviceKeyStoreTests records. TSS.Net's own TcpTpmDevice cannot reach swtpm: it opens the platform socket too and exchanges a handshake only the Microsoft reference simulator answers, so Connect() blocks with no error and no timeout. SoftwareTpm speaks the data channel and nothing else. The suite also lied once and was fixed: the lockout test trips shared state, and without a DictionaryAttackLockReset in Dispose every later test got null from a correct PIN — six of them assert null and passed for entirely the wrong reason. End to end on a real Fedora 44: a genuine linux-x64 publish packages, installs, and every DT_NEEDED in the installed tree resolves except liblttng-ust, which is the one this spec deliberately excludes. What no runner covers is /dev/tpmrm0, PackageKit and polkit, and Phase 19 grew five checks for exactly those. Also fixed: the magic-bytes literal picked up raw control characters, which made LinuxDeviceKeyStore.cs binary to git — no diffs and no line-ending normalisation.	2026-08-22 20:02:30 +02:00
jaap-jan	882f01c515	Type a path on the SFTP pane, and put a file right without deleting it ... Three things the file browser could not do. Somewhere to go had to be walked to, a file that landed under the wrong name could only be removed and sent again, and the listing went on showing the directory as it was before this application put something in it. ◆ THE PATH IS A BOX NOW, not a TextBlock printing where the pane was. A breadcrumb only reaches what is under the directory already listed, so crossing a host's filesystem cost a click and a round trip a level, and a path somebody already knew could not be entered at all. Enter goes; Escape puts back what the pane is really showing. What is typed may be absolute, relative to the directory showing, or start at ~ — the four shapes a shell takes, because somebody typing into a box is typing what they would type into a shell. SftpPath.Resolve turns all of them into one absolute path, and it resolves them here rather than handing a relative path to the server: the server would resolve it against the session's own working directory, which is not necessarily the directory the breadcrumb above the box is showing. `..` is collapsed textually, which differs from cd through a symbolic link; the alternative is a realpath round trip before anything lists. The box holds its own value rather than RemotePath itself. Binding it straight to the path would navigate on every keystroke — `/`, then `/v`, then `/va` — a round trip and a failed listing per character. Every other way of moving writes the real path back into it; a refused listing deliberately does not, because the path that did not resolve is the one worth having in front of you. ◆ RENAME AND MOVE, and DELETE moves to join them. It had been sitting in the pane header beside UP and REFRESH — two things that move the pane and one that destroys a file, in one row — and the three that act on the selected row are now together in a row of their own, under the name of the row they are about. One SFTP rename underneath both new operations and two separate questions on the screen, because the answer is a different kind of thing each time: a rename takes a name and must not take a path, a move takes a directory and must not take a name. One box asking for a destination path would be fewer controls and a worse question — the two mistakes it invites are exactly the ones the split makes impossible. Each form opens on the answer that changes nothing, so what gets edited is the half somebody came to change. Three refusals are made here, and they are the ones a server's message would not explain: a separator in a name (no such file, about a directory nobody meant to name), a destination equal to the source (success, and a file that did not move), and a directory into itself (EINVAL, true and useless). Everything else is the server's — a name already taken, a path that is not there, a mount that cannot be crossed — and arrives in the status line in its own words. Neither is painted in the deletion card's red: a rename is undone by renaming back, and spending that red twice makes it stop meaning anything. ◆ THE LISTING REFRESHES ITSELF when a transfer lands in it. Both panes, since an upload lands on the host and a download lands here and either leaves the pane that is showing that directory a step behind. Only the directory actually on screen: a queue moving a hundred files elsewhere must not be a round trip per file for a listing nobody is looking at. It waits rather than interrupting. Another operation running would have two listings racing for one collection, and re-listing under an open question is how the row somebody answered about stops being the row that gets acted on — so the staleness is remembered and settled at the end of the operation or when the question is dismissed. It says nothing either way: nobody asked for it, and the status line at that moment is carrying the news about the transfer. The selection survives, re-found by path, which is what makes an unasked-for refresh safe to run under somebody's pointer at all. ◆ THE LAYOUT SUITE FOUND A REAL FAULT and the fix is where the height goes. The rename form did not fit the 204 pixels the session shell's own sidebar leaves this pane — MKDIR and the listing were pushed off the bottom. The form is shorter now (the placeholder says what the box wants, so there is no field label above it), and the item row and the breadcrumb step aside while any of the three questions is up, which is what the phone head already did with its own buttons. Measuring also settled something the markup had been claiming and is not true: at that width the listing collapses to nothing under any of the three cards, the deletion card included, and has done since the sidebar arrived. So "the row it is about is still on screen" is retired from the deletion card's remark, and the full path each card carries is what identifies the row instead. Recorded where it is drawn rather than left to be rediscovered. TESTS. SftpPath.Resolve gets the four shapes, ~ with and without a home to expand it to, a blank box, and climbing past the root. ShellFlowTests gets nine against a session that records what it was asked to do — which path was renamed, which directories were listed — rather than against the sentence this code writes about itself: the path box absolute and relative, rename in place, the separator refusal, a move by relative path, the no-op refusal, the three questions displacing each other, and the three rules the automatic refresh follows. The local half is in TransferQueueingTests, where a real folder answers. Two new shapes are measured, and the deletion card's own measurement moves to the connected state — the only state it can be asked in, and the narrow one. What the tests cannot reach is in docs/manual-checks.md as phase 2b: a real server's cross-device and name-taken refusals, and a soft keyboard, which is why the phone's path box has a GO button rather than trusting whatever the IME decided to draw on its return key.	2026-08-21 12:05:33 +02:00
jaap-jan	68964d8a34	Merge pull request 'Name a quick-connect result's vault, and search on it' (#13) from claude/search-items-vault-display-865eb0 into main ... Reviewed-on: #13	2026-08-14 09:13:16 +00:00
jaap-jan	e252d337d1	Take the SSH.NET release that fixes the SCP path traversal ... Every project in the repository stopped building, on a warning about a package none of them had changed: error NU1903: Warning As Error: Package 'SSH.NET' 2025.1.0 has a known high severity vulnerability GHSA-q939-rpr3-3284 was published after the pin was written. ScpClient.Download in recursive mode takes the filenames the server sends and joins them to the local destination without validating them, so a malicious or compromised SCP server can name "../" its way out of the download directory and write anywhere the client process can — CWE-22, 7.1, and the same shape as OpenSSH's CVE-2019-6111 with the traversal left in. Everything up to and including 2025.1.0 is affected; 2026.0.0 is the fix. ◆ THIS APPLICATION WAS NEVER EXPOSED, AND THE UPGRADE IS STILL THE RIGHT ANSWER. Nothing here constructs a ScpClient. File transfer is SftpClient throughout — SshNetSftpSession is the only path to a remote file — so the vulnerable method has no caller to reach it from. That makes this a hygiene bump rather than an incident, and it is worth saying plainly because the alternative on offer was a scoped NuGetAuditSuppress with that reasoning written beside it. A suppression is what you reach for when there is nothing to upgrade TO. There is: the maintainers shipped the fix, taking it costs two nullable annotations, and a suppression would have left this repository carrying a known-vulnerable library and a comment explaining why that is fine — which stays true only until somebody adds the first ScpClient call and has no reason to look here. BouncyCastle.Cryptography moves 2.6.2 -> 2.7.0 as a consequence, not a preference. CentralPackageTransitivePinningEnabled makes the PackageVersion here the resolved version for a transitive dependency, and SSH.NET 2026.0.0 asks for 2.7.0, so a pin left at 2.6.2 is a downgrade error rather than a version this repository gets to choose. Its comment records the constraint so the next person does not try to walk it back. ◆ THE RELEASE NOTES SAY NO BREAKING CHANGES. THE NULLABLE ANNOTATIONS DISAGREE. ConnectionInfo.CurrentServerEncryption is now string? — correct of them, since it really is null until the key exchange completes — and that is CS8601 at both places this codebase reads a cipher off a live connection. Neither can observe the null: SshNetConnection and SshNetSftpSession are only ever constructed after ConnectAsync has been awaited, which is what their existing remarks already say and why the reads are at construction rather than lazy. Coalesced to string.Empty rather than silenced with !, because empty is already this codebase's word for a cipher that could not be read. MainWindowViewModel's NullIfEmpty exists for exactly that, TerminalWorkspace.GetSessionFacts already hands over string.Empty on the same grounds, and the status bar collapses on it. So the boundary keeps the interface's non-nullable string, no consumer changes, and an unreachable null would degrade the way a real one already does. SshNetConnection's remark asserted that SSH.NET types the property non-nullable and that reading straight through was therefore honest rather than lazy. That sentence is now false, and a comment contradicting the line beneath it is worse than no comment, so it says what is actually true: the coalesce is there for the annotation and the pre-key-exchange window this call site cannot be in. The Android head needed its own restore. It is outside DodoSSH.slnx, so the solution-wide --force-evaluate does not reach it, and left alone it would have kept the vulnerable pin and gone stale under locked mode — the hazard platform-flags.md records, arriving on schedule. Heeding the warning left by the ILLink commit: --force-evaluate on Windows rewrote all 39 lock files with CRLF, and 21 of them had no content change. Only the 18 that really moved are here. Verified with `dotnet build` at the root, no audit-disabling flags: 0 errors, NU1903 gone, and the 21 remaining warnings are the pre-existing Meziantou/CA and Avalonia ones that were present in the failing build too. A library upgrade is not a version string, so the suites that exercise it were run against live containers rather than trusted: 87 Ssh, 80 Terminal, 27 ObjectStore, 10 Transfer, none failing.	2026-08-14 09:36:24 +02:00
jaap-jan	fdea3911c1	Name a quick-connect result's vault, and search on it ... Ctrl+K reaches every vault the session holds a key for — that is deliberate, and it is what makes the palette worth opening from anywhere. What it did not do was say where a result came from. A team and a person who both call a machine prod-db got two identical rows, and Enter took whichever the ranking happened to put first: the same three characters, two different machines, depending on nothing anybody could see. Nothing new is computed for this. HostRowViewModel.VaultBadge has been filled in since the host list learned to span vaults, and it is already drawn on the hosts board, the keychain, the snippets list and the known-hosts pane. The palette was the one list reaching across every vault that did not print it. ◆ THE VAULT IS THE LAST OF THE FOUR RANKS, AND THAT IS THE POINT. A vault name is the widest reading of the three the palette had: one word matches every host in that vault at once, where a name or an address matches one machine. So it sits behind name-starts-with, name-contains and address — otherwise typing a machine's name would bury it under everybody else's. It matches on HasVaultBadge rather than on VaultName, so the search only ever matches what the row actually shows. A session holding one vault prints no vault on any row, and matching it there would answer "personal" with the entire keychain, ranked behind nothing and explained by nothing on screen. In the row, the right-hand column becomes two lines against the two on the left, in the same order: what this is above, how it is reached below. With one vault the badge is empty, the line collapses, and the kind word stays centred exactly where it was. The name is capped and ellipsised because that column is Auto-sized — a long vault name would otherwise take its width out of the host name beside it. Three tests, one per claim. VaultSharingTests puts platform-gateway in the personal vault and prod-db in "Platform secrets" and types "platform": both come back, the gateway first. ShellFlowTests types the personal vault's own name into a one-vault session and gets nothing. QuickConnectTests is the markup's half — the shared vault's row draws PLATFORM SECRETS, and a one-vault row draws no vault at all — with the shared vault put into the session through the layout suite's own StubTeamServer, as the settings pages' suite does it. 449 App tests and 155 layout tests pass. Both suites were run with -p:NuGetAudit=false: SSH.NET 2025.1.0 has picked up GHSA-q939-rpr3-3284 and NU1903 fails restore repo-wide, which predates this branch and is nothing to do with it. No package or lock file is touched here.	2026-08-14 09:35:44 +02:00
jaap-jan	25407756c3	Look for a newer build the moment the application starts ... The first pass of the update loop waited two minutes. Every pass after it came six hours apart, which is the right interval for a product that ships rarely — but the delay in front of the first one quietly excluded a whole way of using this application. A client opened to reach one host and closed again is over before the two minutes are. Used that way, it never checks at all: not once, not slowly, never. That is precisely the machine ADR 0011 names as the real cost of distributing outside a store — quietly a year behind — and the galling part is that the mechanism to fix it was switched on the whole time and simply never reached. The delay's own argument is recorded in the diff it is being removed from, and it was not a bad one: nothing anybody does in their first two minutes depends on an update, and launch is already contending for the network with a schema migration, a resumed sign-in and a first sync, at the one moment somebody is watching the window. What it weighed was the cost of checking early against the benefit of checking early. It never weighed the cost of not checking at all. ◆ THE YIELD IS WHAT KEEPS THIS OFF THE LAUNCH PATH, AND IT IS NOT DECORATION. Start() is called from MainWindowViewModel.StartAsync ahead of the migration, so an inline first pass would run whatever the channel does before its own first await — Velopack reads the install layout from disk — between the user and their window. Yielding hands the rest of launch back and puts the check in a later turn, which is the same moment in every sense anybody can perceive and none of the cost. So the answer to the delay's argument is not that it was wrong; it is that a yield buys most of what two minutes bought. Task.Yield takes no token where Task.Delay did, so the loop body now observes cancellation at its head. Without that, an application closed during launch spends its last moment asking a release channel about a build it will not run. Two things deliberately not changed. The AUTOMATIC UPDATE CHECKS preference still gates the pass — "on start" means every start, not regardless of what the user asked for, and that setting is already on by default. And the data cost is unchanged rather than merely acceptable: a check is a few hundred bytes and the download only follows if something newer exists, so this moves the same traffic earlier without adding any. That matters most on the phone, where the same loop runs against AndroidUpdateChannel. TheFirstPassRunsAtStart_RatherThanOnADelay drives the real loop rather than CheckOnceAsync, which is the one thing that file otherwise avoids — and here it is the point, because the claim is about when the pass happens rather than what it does. It waits on the pass and not on a clock, so there is nothing to be flaky about: a regression that puts a delay back does not fail on a margin, it spins until the suite's own cancellation ends it. DisposingStopsTheLoop keeps its assertion and gains a note that it is now a race rather than a formality. §16.7 of the manual checks gains the sentence that reopening the application does what CHECK NOW does. It is the step somebody following that section would otherwise discover by accident. 447 App tests and 153 layout tests pass.	2026-08-12 12:03:54 +02:00
jaap-jan	ccaf7a8e72	Give the terminal back the width and the keyboard the session shell took ... Seven things reported from a day's use of v5b's session shell, and they are one commit because five of them are the same complaint from different angles: the window spends too much of itself on chrome describing the session, and the parts that are not chrome do not behave. ◆ THE HOST HEADER IS GONE, and that is a deliberate departure from the design. Terminal.dc.html and SFTP.dc.html both draw a 60-pixel row above the pane: the address on the left, a cross-surface button on the right. Both facts are worth having and the strip they sat in was not — the tab already names the host, and a full-width bar repeating it was the cheapest 60 pixels in the layout to give back. The address is now the first line of the sidebar and the button is stretched across the column under it, so nothing is lost and the pane is taller. Which word that button carries and which command it runs used to be handed in from the two usage sites in MainWindow.axaml, because the control was drawn twice. One sidebar cannot do that, so SessionCrossSurfaceLabel and OpenOtherSurfaceCommand resolve it in the shell — the same place SessionAddress already decides which surface's fact to read. The two directions underneath are untouched: SelectFilesHostAsync for a tab's host, OpenTerminalForFilesHostAsync for a fresh terminal at whatever SFTP has open. SessionHeader.axaml is deleted rather than left unused, and LayoutHarness stops subtracting its 60 pixels from every session screen's budget — the same treatment the retired window-wide tab strip got, and for the same reason: a constant for chrome nobody draws is a suite quietly measuring the wrong rectangle. ◆ AND THE SIDEBAR CLOSES, which the design has no state for at all. 300 pixels of an 1081-pixel minimum is a great deal to spend on a list that is often two rows long. The column now folds to a 34-pixel rail carrying the chevron that brings it back — a rail rather than nothing, because a panel that vanishes leaving no trace is one people report as lost rather than as closed. Both states live in the one control and swap on IsSessionSidebarOpen, so MainWindow's own "Auto" column takes whichever width is showing without knowing the state exists. Written through to ClientSettings.SessionSidebarOpen rather than held for the session. It is a decision about how much of the window a terminal gets, and one that had to be made again on every launch would not really be on offer. ---- THE FOUR SMALLER ONES ---- A SNIP LANDED IN A TERMINAL NOBODY COULD TYPE AT, and looked selected when it got there. Two causes with nothing in common. The click moved Win32 focus onto the sidebar row, and term.focus() in the page cannot take it back — only the host can, so the shell raises TerminalFocusRequested and the window answers with the same posted focus every other path here uses. The highlight was bash: xterm wraps a paste in bracketed-paste markers, readline marks what arrives inside them as an active region, and it stays in reverse video until the next keystroke. Right for a clipboard paste, wrong for a snippet picked off a sidebar. Single-line snips are typed rather than pasted now, which needs no markers; multi-line still pastes, because "runs three commands unasked" is the worse of the two failures and the markers are the whole of what prevents it. A BLACK BAR UNDER THE TERMINAL, on Windows. xterm.css paints its scrolling viewport #000 — its own comment explains why, and it is a macOS scrollbar concern. Everywhere else that black is covered by the rows, except along the bottom: the fit addon floors the row count, so the remainder below the last whole row is bare viewport, up to a line tall, against this page's #171a26. The light square at its right-hand end is where WebView2's classic scrollbar corner lands. The viewport is repainted in the page's own background, and the scrollbar with it — thin and in these colours rather than a grey Windows channel down the side of a near-black terminal, and kept rather than hidden, because a surface that scrolls with no sign that it does is worse than a quiet bar. THE PINS ROW DREW A TOFU BOX. U+E946 is not in the embedded Material Icons face at all — that file is the 2019 build and its cmap skips E944 and E946 — so the rail's Pins row and the hosts screen's own pin badge have both been drawing a missing-glyph rectangle since v5b picked the codepoint. push_pin in that vintage is U+F10D, verified against the file rather than against a codepoints table for a later release of the font. Every other icon codepoint in the repository was audited the same way; this was the only miss. THE KBD CHIP CUT THE CHORD IN HALF. 34 pixels is the design's width for a chip reading ⌘K, and this build substitutes CTRL K — six characters and a space, wider than 34 at 10.5 mono. MinWidth and padding instead, so the design's footprint survives for the day this face has a ⌘ to draw. ---- AND THE POPOVER UNDER THE USER CHIP ---- Reported as not matching the design, and it was not: Button.poprow set a corner radius and a padding and never touched the Background, so every row wore the Fluent theme's own #33FFFFFF button fill. Six raised pills stacked in a menu the design draws as six lines of text — and the hover rule underneath was already correct and simply invisible against a fill that never went away. Set on the ContentPresenter as well as on the Button, the same as Button.flat, because the theme binds its brush there and a Background set only on the control loses to it. The panel itself gets this window's own radius-12 card treatment through a FlyoutPresenter class rather than by widening the shared context-menu rule, and Vaults and Preferences stop being drawn one step dimmer than Settings and Logout, which read as two disabled entries in a menu of five live ones. ---- WHAT PROVES IT ---- Three tests in the layout suite, two of them checked against the defect they describe: the popover row's resting fill (fails with #33ffffff without the style), and the kbd chip against the natural width of its own text, measured on a detached copy because a TextBlock's DesiredSize is already clipped to what it was given and reports 34 inside a 34-pixel chip either way. SessionSidebarTests is new — the sidebar has never been laid out by a test, and it now holds a string of unbounded length beside a button that has to stay clickable. In the shell suite: the cross-surface row in both directions, the closed state surviving to disk, and the focus request being made when a snip lands and not made when it does not.	2026-08-10 16:49:44 +02:00
jaap-jan	8a77b7ca68	Say how far a connection has got while it is still being made ... The connecting card set its status string once, when the tab was created, and never touched it again. Every connection therefore looked identical from the outside: one three seconds into a key exchange, one waiting out a fifteen-second timeout against a machine that is asleep, and one that had hung all drew the same "connecting…". The card now draws the five steps of getting there, each lit at the moment the handshake reports reaching it, over an amber track that fills as they finish. ◆ NOTHING ON THE LIST IS INVENTED. Every row changes state because a layer below it said so, at the instant the thing it names actually began. That is the whole reason it is worth showing, and it is why most of this commit is plumbing rather than XAML: there was no progress reporting anywhere in the stack to hook a step list onto, and a card animating plausible progress would have been indistinguishable from one that had stopped receiving any. SshConnectionPhase names four phases and deliberately not more. SSH.NET runs the entire handshake inside one ConnectAsync and raises exactly one event from the middle of it — HostKeyReceived, once the key exchange has produced a key to show — so that event is the only interior moment there is to report. Everything before it is Reaching and everything after it is Authenticating. A fifth phase in that assembly would have to be a timer, so there is not one. OpeningShell is reported by TerminalWorkspace instead, because that is where it happens: the factory's work ends with an authenticated connection, and asking for a pseudo-terminal on one is a separate round trip. The SFTP path passes null — a second connection opened behind an already-open shell has nobody watching a step list for it. The card's fifth step, "Starting the terminal", is the renderer wait and lives in the shell rather than in the SSH assembly, which has never heard of a renderer. On the first connection after a cold start it is a real wait with a real failure mode of its own — a missing WebView2 runtime — so a list that began at "reaching the host" would leave the one wait most likely to hang unnamed. Amber for the step in flight, and that follows the palette's rule rather than bending it. Green is what is true and purple is what you can press; a step still happening is neither, and it is exactly the caveat-worth-reading that amber exists for. Steps behind it go green as they become true. Nothing animates, which is the argument TransfersScreen.axaml already makes for its own track, reaching a screen with far more reason to want a spinner: a spinner is furniture invented to fill a state nobody measured, and these states are measured, so the track fills to what has finished and then waits there. A refusal keeps the step it stopped on, in red, with the ones behind it still green. That is the half a progress bar could not do, and it is the difference between "that host is not there" and "that host is there and would not have me" — a question the reason sentence alone frequently does not settle. The strip's dot goes amber while a tab is connecting, on both heads. It was grey, and so is a tab whose shell has exited: the two states in that strip with the least in common, one worth waiting for and one over. PhoneShell's own comment already recorded half of this — the dot stopped being green before anything had answered — and this is the other half. Progress is raised inline rather than through System.Progress<T>, which captures whatever synchronisation context it was constructed on and posts to it. That reads like a convenience and is really a second place the marshalling decision gets made: silently, differently under a test with no context, and out of order with respect to the failure that follows a phase. The shell marshals once, in one handler, through a new optional post parameter on MainWindowViewModel — the same seam TransfersViewModel already uses, and for the reason its own remark gives. The three Dispatcher.UIThread.Post calls that predate it are the ones this suite's comments record as out of reach; they are left alone rather than swept in here. Both heads draw the list. They differ in one place: Phone.axaml's mono class sets a colour and a size along with the family, so the caption rule names its own family instead of composing the two and asking two rules for one Foreground. The desktop's mono sets the family alone, which is why ConnectingCard does compose them. Each head also gains SHOW LOGS beside the button that gives up — the step list is this attempt and the log is every other one, which is what a connection taking too long actually raises. Seven tests, and the two that matter most run against the container rather than a fake: a real handshake reports its phases in order, and a host-key refusal never claims to have authenticated. A fake asserting what it was written to assert would have established nothing about either. The rest cover the tab advancing while the connection is gated, the step a refusal stops on, and a phase reported after the user has given up on the tab. 1,861 tests, none failing. The Android head's layout is not verified by anything. It compiles, and compiled bindings mean every new binding path resolves, but that project is not in DodoSSH.slnx, there is no test project for it and no device here — so unlike the desktop card, whose shapes the layout harness measures, these rows have not been drawn. Vertical fit is reasoned, not observed.	2026-08-10 15:47:45 +02:00
jaap-jan	e96d01aab9	Let the host editor make the credential it is about to bind ... The authentication picker has listed saved credentials since they existed, but making one meant leaving a half-typed host for the keychain screen and coming back to find it gone. On the phone it was worse than a detour: that head has no credential editor at all, so it could bind a host to a credential and never produce one. + NEW CREDENTIAL opens a card under the picker — name, optional username, password, notes — and ADD writes it and binds the host in one step. A button beside the picker rather than an entry inside it. Every row of that list is a binding a host can have, and "make a new one" is an action: as an entry it would sit in the box afterwards describing a state no host can be in, and cancelling the form would leave the picker showing it. It carries its own five fields rather than reusing the keychain editor's, and that is the load-bearing part. IsEditingCredential is what AVaultEditorIsInTheWay asks about, so sharing it would have made the whole Vault screen refuse to open an editor while this card sat open on the Hosts screen, with a status line naming a form the user cannot see on a screen they are not looking at — the exact failure that guard was split in two to end. A test pins it. It writes to the keychain immediately, unlike every other field in this editor, because a credential is a shared item with an id and a host can only name an id that exists. The consequence is honest rather than hidden and the hint says so: a credential added this way outlives a cancelled host edit. What was still being typed does not — every path that closes the host editor clears the form, and one of those fields is a password. The binding is written before the reload rather than after it. RefreshOpenEditors rebuilds this picker and then restores it from the editor's own selection, so setting it first is what survives the pass, and by the time it is read ReloadCredentialsAsync has put the matching entry in the list to land on. A name already taken is duplicated, not reused, and that is a deliberate parting from the new-tag box six lines further down which offers the existing tag instead. Two tags called "staging" are one intention spelled twice; two credentials called "root" are two different passwords, and quietly binding the host to whichever was there already would authenticate it as an account nobody chose. A duplicate label in the picker is the smaller problem. Into editingHostVaultId, so the credential lands wherever the host is being sealed and everybody who can read the host can read what it authenticates with. Stricter than the tag path — which files into the active vault and is recorded as a gap in docs/design-import-gaps.md — and it can be, because this picker lists credentials from every readable vault rather than one. Five flow tests cover the bind-through-reload path, the cancel semantics on both the saved credential and the abandoned one, the cross-screen guard, the duplicate name and the empty-password refusal. The layout test is separate and necessary: the card is collapsed until somebody presses the button, so a harness driven by the default state draws none of it, and TheHostDrawerFitsWithTheHostEditorOpen would have gone on passing over a card that blew the column. 1,854 tests, none failing.	2026-08-10 11:23:10 +02:00
jaap-jan	810bc48d3f	Tell the keep-alive wire when the Files session opens and closes ... HasLiveFileSession answers the phone's foreground-service question — is there a connection here that dying with the process would sever — and a bucket answers no, because HTTP holds nothing open. ActivityChanged now also fires at the end of MarkHostConnected and CloseSessionAsync, where both facts it reads are finally true together. Also makes the bucket pins test actually open a bucket: it never set Remote, so CONNECT dialled the auto-selected host, and its assertions passed only because that host had no pins either.	2026-08-09 10:14:10 +02:00
jaap-jan	dbf6ce1bcf	Give the phone its pins: an editor section and chips on Files ... The data was never the gap — HostSecret.PinnedPaths syncs and merges on both heads, and the desktop's drawer has staged it since v5 — the phone just had nowhere to add, remove or use a pin. Now it has both halves. The host editor page gains a QUICK ACCESS section over the same shared staging the drawer binds (EditorPinnedPaths, AddEditorPin, RemoveEditorPin), with the remove target at this head's 44dp touch floor rather than the desktop's 22-pixel close box, and no folder glyph because this head embeds no icon font for one. The page also gains a Status line of its own: the add command's five refusals speak through Status, and this page covers the screen that normally draws it — a refusal nothing shows is no refusal at all. The Files screen draws the connected host's pins as chips between the breadcrumb and the listing, each running GoRemoteCommand exactly as a crumb does. They are captured at connect, like ConnectedTo and the session facts before them; a bucket gets none, having no HostSecret to pin anything on. Covered headlessly in ShellFlowTests — connect populates, disconnect clears, a bucket stays empty — and by manual checks 8.18 and 8.19, whose phase preamble also stops claiming thirteen checks when it lists twenty-one.	2026-08-08 23:09:57 +02:00
jaap-jan	242280ce6b	Name a root chip after the root, not with its whole path ... The chip derivation was TrimEnd(separator), which is a name only for the Windows drives it was written against: on Unix it made the / chip an empty pill and the home chip the entire home path, drawn at full width in a header column nothing bounds. A home directory deep enough — CI's per-job HOME is forty-six characters — had that one chip walk the header's own buttons out of the window at the session shell's 472-pixel budget, which is the half of the runner's red suite the star-column fix before this one did not reach. A chip says C:, /, ~, or a mount's last segment now; the full path stays on its command parameter, where length costs nothing. RootChipNameTests pins the derivation with fixed strings, so it no longer takes a machine with a deep profile path to ask the question.	2026-08-08 22:38:41 +02:00
jaap-jan	009b35e069	Cover the mixed-keychain regroup refusal headlessly ... The two-keychain branch of VaultViewModel.RegroupChosenHosts had no test: 7.6a's manual walk was the only thing asserting that a mixed set gets the sentence instead of the picker. A ShellFlowTests case now ticks a host in each of two vaults, reads the refusal off the status line, and shows the same command opening the picker once the set is one keychain's again. Check 7.6a cites the test and keeps only the popup wiring for the eye.	2026-08-08 22:19:46 +02:00
jaap-jan	9d5ff9f23a	Draw what authenticated, and over what, on the session status bar ... The v5b design's own row: the negotiated cipher, then the host key's algorithm and the name of the key or credential that authenticated, as one mono run beside CONNECTED — on both surfaces, off MainWindowViewModel's surface-aware SessionCipher and SessionIdentityText, the same shape SessionAddress set. The identity's name comes out of TryBuildAuthentication, the one resolution point that always had it in scope and always threw it away; it rides HostAuthentication to the tab and to the SFTP connect alike. Three deviations, recorded in the gaps doc: the algorithm prints as negotiated rather than shortened, the run is plain text because no pin-details modal exists for an open session, and a typed password shows the algorithm alone — there is no item behind the dot. A dead terminal tab keeps its facts for the scrollback still on screen; an SFTP disconnect, with no scrollback, clears them.	2026-08-08 20:54:56 +02:00
jaap-jan	8209f15741	Let a session's transport say what it negotiated ... ISshConnection and ISftpSession both carry Cipher now — the server-to-client algorithm off SSH.NET's own ConnectionInfo, captured once because a rekey is not an event that library raises — and TerminalWorkspace.GetSessionFacts hands that plus the host key's algorithm back per session, without ever handing over the connection itself. Nothing reads either yet; the status bar that will is the next commit.	2026-08-08 20:54:14 +02:00
jaap-jan	c8507b44fe	Give the application a settings area built from what really exists	2026-08-08 14:17:19 +02:00
jaap-jan	43c939b697	Give the window its v5b chrome and each session surface its own shell	2026-08-08 00:49:59 +02:00
jaap-jan	281e828e25	Sweep out the group-card navigation nothing reaches any more	2026-08-07 18:14:54 +02:00
jaap-jan	2ba7c14e35	Restyle the drawer, pin folders on a host, and say when it was last connected	2026-08-07 18:12:31 +02:00
jaap-jan	507cd9ff88	Choose more than one host card on the desktop, the way the phone already can ... The chosen-hosts set has been in VaultViewModel since the phone's connect card became a contextual action bar: a set of entity ids, a tick on the row, and seven things that can be done to it. Only one head could fill it. The desktop's grid answered a press with one selection — the card the drawer, CONNECT and the context menu are about — so filing eleven imported machines under a heading was eleven drags, and clearing out a vault was eleven rounds of the deletion question. So the pointer gets three ways into the same set. Ctrl-clicks a card to tick it, Shift-clicks to tick the run between the anchor and the card, and drags a band out over the space between and below the cards to tick everything it touches. Esc, CLEAR, a plain click on a card and a click on the empty space each drop it, and Ctrl+A takes every card being drawn — VisibleHosts, so with something in the find box that is the ones on screen and not the ones it is hiding, which is the version of that shortcut whose result can be checked before Delete is pressed. TWO SELECTIONS ON ONE SCREEN, AND KEEPING THEM FROM DISAGREEING IS MOST OF THE CHANGE. Ctrl and Shift are answered on the tunnel and marked handled, so the ListBox never moves its own mark onto the card: a Ctrl-click that also selected would light the card it had just unticked and open the drawer on a machine somebody is removing from a set. A plain press drops the set unless it lands on a ticked card, and that case is deferred to the release, because the press may be the start of a drag of all of it. After any ordinary click exactly one card is in play, which is what makes every command on the screen unambiguous again. The context menu is where the seven live, and it is one markup with two halves gated on IsChoosingHosts. Connect, Browse files and Edit… are drawn only for a single ticked host, as the phone's sheet collapses them and for the same reason; the other four read better for a count. A right click on a card outside the set drops the set first, so a Delete… about the card under the pointer can never be offered while six sit ticked behind the menu — the same rule OnContextRequested has always enforced for the selection, reached from the other direction. No bar of buttons: the phone raises one because it has no other way to hold seven entries, and a strip repeating a menu that already exists would be a second home for the wording that matters most. What the desktop gains instead is a count beside the HOSTS heading, CLEAR, and a sentence saying where the actions are. A drag that starts on a ticked card carries every ticked card. The payload is a list rather than a row now, and a drop of more than one goes through FileChosenHostsUnder, which makes the refusals once — an open editor, and a group belonging to one keychain — and reports a count instead of forty status lines. Moving whichever card the pointer happened to be holding and leaving the other five where they are is a gesture that quietly does a fraction of what it looks like it does, and the five left behind look filed. The three panels the set's actions raise had never been drawn in a window: the vault picker with its key question, the group picker, and the deletion question. All three sit above the grid rather than over it, which is the arrangement the GROUPS section and the phone's list already use and for the reason written there — the ticked cards are the information the question exists to give, so the grid shortens instead. A DEFECT FOUND BEHIND IT, AND IT WAS ALREADY LIVE ON THE PHONE. The deletion question names a count and the run that answers it reads the set again, and nothing kept the two the same set: the panel is deliberately above a live list, so one more tick between "Delete these 6 hosts?" and pressing DELETE deleted seven, with the seventh named in nothing the user had read. It needed a deliberate act on a phone and a second's work with a band, which is what turned it up. VaultViewModel now remembers which hosts the question was asked about and drops the question when the set stops being them — the question rather than the set, because what somebody has just chosen is what they meant. It also covers the case nobody performs: a colleague's deletion arriving mid-question and shrinking the set under it. VERIFIED. 354 tests in App.Tests and 111 in App.Layout.Tests, build clean, no new warnings. Six gesture tests drive real pointer and key input through the headless window — the modifier click and what it must not do to the selection, the run and its re-measurement from the anchor, the band and the click that drops the set, Ctrl+A under a filter, and the menu's two halves — plus a DragOver carrying two hosts. Four layout tests measure the strip and the three panels at the window's minimum; the vault panel binds a key to its host first, or it would measure the short shape and certify the tall one. Two flow tests cover the multi-drop's write and its refusal, and the deletion question dropping itself. manual-checks gains 7.6a for dragging a set, which no test can see for the reason 7.6 gives, and 7.7a for the gestures — the rectangle actually being painted and the tick and the fill being legible together are the two things the harness cannot look at.	2026-08-06 14:11:48 +02:00
jaap-jan	1e8a1f2e83	Merge branch 'claude/trust-connect-popup-56abec'	2026-08-06 12:27:20 +02:00
jaap-jan	4f9faa2fe3	Ask about a host key where the connection was made, not on the host list ... The trust prompt was two banners at the top of the desktop's hosts screen, so the shell navigated there before letting a handshake raise one: Screen = Hosts, Surface = Page, in OnVaultConnectionFailed and again in the palette's own connect. The reason was sound — a connection can be started from Ctrl+K on any screen, and a question behind whatever somebody is looking at is a question nobody can answer — and it was answered the wrong way round. Rather than making the decision reachable from where the user is, it moved the user to where the decision was, and charged every screen for it. It is worst for the one connection that has no host at all. A machine typed into the phone's connect box is deliberately in no keychain, so a first contact from there judged it on a list it does not appear on, after taking the box that dialled it away. So both heads now draw the decision over the surface. HostKeyCard is the desktop's, and is the counterpart of the phone's HostKeySheet: a scrim with no press handler, because a question with two named answers must not be answerable by missing; the unknown key offering TRUST AND CONNECT, because judging a fingerprint against what an operator published is a decision a person is entitled to make and the only moment they can make it; and the changed key offering no way forward at all, because a button beside that warning is "continue anyway" with two clicks instead of one. The phone needed no new markup — its sheet was already a shell-level overlay, so deleting the navigation is what puts it over the Connections screen. IsHostKeyDecisionShowing is on the shell rather than on a screen because the answer decides an occlusion. A second connection can be refused while a first one is open, so this card is routinely raised over a live terminal, and that rectangle is a native child window: layered over it the card would be sliced at its left edge with TRUST AND CONNECT taking no clicks, which for the most safety-critical question in the product is the worst place for that class of bug to land. IsTerminalShowing gives the rectangle up instead. The banners are gone rather than copied. One prompt in two markups is two copies of the most safety-critical wording here, and the second is the one that goes stale. TWO DEFECTS FOUND BEHIND IT. VaultViewModel.RejectHostKey cleared only the pending key and never the mismatch, so the changed-key refusal had no working exit. That was invisible for as long as it was a banner nothing was drawn over — nothing was trapped, and the next attempt cleared it — and it was already live on the phone, where that refusal is an opaque full-screen panel whose one button runs this command: pressing it left the panel up over every screen the user went to next, including the host editor the panel tells them to open. TransfersViewModel.RejectHostKey has always cleared both; the vault's was the outlier. Its button said BACK TO HOSTS, which was wrong twice over, and now says BACK. And an assertion written for this change could not fail: the palette test asserted the renderer was collapsed in a scenario whose only tab had just been removed, so it was collapsed for want of a session whatever the occlusion rule said. It is gone, with a note pointing at the test that can fail on it. VERIFIED. 1580 tests, build clean, no new warnings, format clean. Three mutations each seen to fail and then seen green again: dropping !IsHostKeyDecisionShowing from IsTerminalShowing, caught by AChangedHostKey_CollapsesTheTerminalItIsRefusedOver; reverting RejectHostKey to clear one flag, caught by RefusingAHostKeyDecision_TakesItOffTheScreen(false) and by that same test; and dropping the two host-key arms from OnVaultPropertyChanged, caught by TheHostKeyDecision_IsAnnouncedToTheWindowWhenItArrivesAndWhenItGoes. That last one is the first test in this repository to watch PropertyChanged, and it is worth being the first: every other assertion about the flag reads it directly, and a direct read passes with the subscription deleted — while the card would never go away. The two layout tests moved with the prompts, from the hosts screen to the card. manual-checks gains 7.4a for the occlusion, 7.4b for getting out of a refusal and 11.7a for the hand-typed case, none of which a test can see; 1.5 and 7.4 are corrected rather than left describing a window that no longer moves. ONE ROUGH EDGE, DELIBERATELY LEFT. On the desktop, refusing a first contact whose tab was the only one leaves the terminal surface with no tabs — a blank rectangle under the strip's "no terminals open · press + or Ctrl+K", which is the one sentence near that rectangle Avalonia can draw. The alternative was falling back to the page, and on the phone that means the host list, which is the bug this commit is about. A desktop connect page would close it properly.	2026-08-06 12:25:37 +02:00
jaap-jan	e750ba05e3	Merge branch 'claude/edit-screen-refresh-items-63a808'	2026-08-06 12:08:55 +02:00
jaap-jan	6d6edb02c1	Keep an open editor's pickers in step with the vault ... The host editor's four pickers were snapshots taken when it opened, and the comment on EditorAuthenticationChoices said why: a picker whose contents move under somebody halfway through a form is worse than a list a minute stale, and only one editor could be open at a time anyway, so the only way to add a key was to close this one. The second half of that stopped being true when AHostEditorIsInTheWay was split from AVaultEditorIsInTheWay. The host editor is the Hosts screen's business and the keychain's editors are the Vault screen's; neither refuses the other now, which was the right split — it stopped three quarters of a screen going inert over an editor the user was not looking at — but it left the assumption those snapshots rested on false and nothing to notice. So the ordinary way of using the feature was the broken one. Somebody starts editing a host, finds there is no key to bind it to, goes to KEYS, makes one, and comes back to a picker that does not have it — with the fix being to throw the form away and start again. The same for a password, a tag, a group, and for a whole vault made on the Teams screen because the host being typed belongs to the team rather than to the person typing it: the vault they had just made for it was the one place they could not file it. RefreshOpenEditors refills whichever editor is open, and it hangs off ReloadAsync rather than off the twenty-odd commands that write to the vault. That is the choice worth stating, because it is what makes a sync count as well as a save: a key pulled from another machine reaches the open editor by the same path a key typed here does, and a place that wrote to the vault without refreshing the editor would be a bug nobody would find for months. What the old comment was protecting against is real, so every picker is put back onto what it was already showing, by id, and not one typed field is touched. An editor that reset its own bindings because a background sync landed would be a worse bug than the stale list this fixes — it would rebind a host as a side effect of somebody else's work. The placeholder entries go back too, which is the case 3.4 measures: a group deleted on another machine mid-edit still cannot unfile the host when the form is saved. The group editor gets the same treatment for the same reasons; it shares the drawer, and its default binding is lent to every host under it. The snippet editor's vault picker was the same copy of the same list and went stale the same way. It watches TargetVaults rather than the reload, because that screen has always been a wrapper over the vault's collections and has no reload of its own to hang off — which is how it already follows Snippets. The move panels are deliberately left alone. A vault arriving from a sync while one is open still will not appear in it, but a move panel is opened by the act that fills it and its picker resets its selection to the first entry on every rebuild, so refreshing it would move a destination somebody had chosen. Same class of bug, different answer, and not this change. Five tests, and four of them were checked failing with the RefreshOpenEditors call commented out: a key reaching the open host editor and binding when chosen, an item arriving without moving a selection that was already made, a tag arriving as an unworn chip, a key reaching the group editor, and a vault reaching the host and snippet editors without moving either. Manual check 7.12 sits beside 7.11, which is this same bug on the files screen's picker, and says what the worse failure would look like: a picker that moves rather than one that does not notice.	2026-08-06 12:08:25 +02:00
jaap-jan	808a9a7fc1	Open a new host in the vault of the group it is being made in ... + NEW HOST decided two defaults separately and let them contradict each other. The group came from the screen — the selected card, or failing that the group whose contents are showing — and the vault came from the keychain screen's standing "new items go to" preference. Inside a group belonging to any other vault the two disagreed, and the group is what lost: GroupInEditingVault drops a group the editor's vault has not got, on the sound reasoning that a host filed under an id its readers cannot resolve looks unfiled to everybody but the person who wrote it. So pressing the button while standing inside a team's PLATFORM opened a form filed under nothing, bound for the personal vault, with no sentence anywhere saying either thing had happened. The vault now follows the group. A group lives in exactly one vault, so a host that is to land in that group has to be sealed in that vault too — which is the rule + NEW GROUP has followed for a parent since the cards became a tree, and the comment there claiming this as a deliberate difference from the host's editor is the one the code has now caught up with. The filter stays, because there is one case left for it: the group's vault may be one this session can read and not write, a team vault this account is a viewer of. TargetVaults is the readable-and-writable set and is what decides here, so a viewer keeps the standing preference and loses the group with it, rather than opening an editor aimed at a save that cannot happen. Both directions are tested, since one alone would not say which default wins: standing in a shared vault's group, the editor opens on that vault with the group selected and the host saves there; and with the preference pointed at the shared vault while a personal-vault group is open, the group beats the picker somebody set once.	2026-08-06 12:08:15 +02:00
jaap-jan	f1d6499bb5	Merge branch 'main' ... Two of main's changes land in files this branch rewrote, and both needed carrying across by hand rather than by the merge. The phone's nav staying up on Connections with nothing running is a fourth input to RefreshChrome, which this branch had already given two more — whether hosts are ticked and whether the host editor is filling the screen. They compose: the rail and the bottom bar now ask (pages || connectPage) && !editing, so a page-shaped terminal surface keeps its way off the screen and the editor still takes the whole display. The key question under the host's move panel is the harder one, because this branch deleted the panel it was added to. The connect card is gone and the phone's only route to a move is the action bar, so leaving the merge to take this side would have removed a capability main had just shipped — silently, since nothing would fail to build. It is asked in the action bar's own picker instead, in two shapes fewer than the desktop's: one host, because which key to carry is a fact about one machine and a selection of six has six answers, and a move rather than a copy, because taking the key out from under an original that is staying put would leave that original unable to connect. BindingOfTheMovingHost splits into MovableBindingOf so both heads answer it the same way from different panels. Main also fixed a real trap in the same commit — a host that only inherited its key from its group arrived in the destination naming nothing at all, because the group stays behind — and the batch move had the same bug for the same reason. It goes through Detached now, which is where that fix lives. The carried host is written as the carry left it rather than being detached again, which is the one thing worth measuring: the key takes a new id over there, so a run that rebuilt the payload from the row would send the machine across naming a tombstone. Both directions are pinned, along with the rule about which shapes the question is asked in at all.	2026-08-06 09:30:00 +02:00
jaap-jan	c882fa0cd3	Give the phone a selection instead of a card under the list ... A long press on a host raised a connect card over the bottom of the list: a password box, CONNECT, EDIT, MOVE and DELETE. It was the right idea in the wrong place. It covered rows, it had room for five things and never a sixth, and every one of them was about exactly one machine — so filing eleven imported hosts under a group was eleven trips through a form, and there was nowhere to put a sixth action if anybody wanted one. A long press now chooses the host it landed on, and the actions move into a bar across the top of the screen, in the vault header's place rather than beside it. That is where Android has put them since contextual action bars existed, and it is the one strip a list can never grow into — but the real reason for it is that while it is up the screen is unambiguously about the ticked hosts and nothing else, which is what lets the count in the middle of it mean something. Left to right: the cross that leaves the mode, the count, the pencil, and a ⋯ holding Connect, Connect via SFTP, Move to vault, Copy to vault, Change group, Duplicate and Remove. A tap still connects and still raises nothing. Once anything is ticked it ticks and unticks instead, which is what every Android list does and is not merely a convention worth following: a tap that connected while five machines sat ticked would open a terminal on top of a selection somebody was halfway through building. Unticking the last host leaves the mode, so there are two ways out of it and the cross is only one of them. Both gestures now read the row from the element under the finger rather than from the list's selection, and that is a correctness change rather than tidying. A tap on a group heading moves the selection and the view model bounces it straight back to whichever host was chosen before — which answered "a host, or nothing" for free while a tap only ever connected. It stops answering it the moment a tap can tick one: the heading would tick a machine the user was not pointing at, into a set they are about to delete. Three of the seven entries are about one machine and are drawn only for one. A terminal, a file-transfer session and a form each have no reading over six, so they are collapsed rather than refused. The other four read better for a count than without one — it is the reason the set exists — and each of them says afterwards how many hosts it wrote and how many it left alone. Skipping beats refusing the whole run: a selection of eleven with one read-only row would otherwise do nothing at all and then report about the wrong ten. Copy to vault and Duplicate are new, and the difference between them is what each can safely carry. A copy crosses a key boundary, so it drops the group and the tags exactly as a move does — both are items of the vault being left, and a host arriving with either would point at something the destination does not contain, resolvable on the machine that sent it and dangling for everybody else. A duplicate stays in the same keychain, so everything it points at is still there and it keeps both. Change group is the write dragging a card onto a group already makes on the desktop, run over a selection; it refuses one spanning two keychains rather than half-filing it, which is the refusal a drop across that boundary already makes one host at a time. Connect via SFTP is the one action that leaves the vault. Which machine is a decrypted item and so is this object's business; the screen it leads to and the transfers view model behind it are the shell's — so it is an event, on the same division SessionOpened already draws for a shell. The host is re-found in that screen's own copy of the list, because the picker binds to rows in that copy and handing it the vault's object would select nothing. What is left of the card is the password box, and only because it had nowhere else to go: a host that authenticates with a typed password cannot be reached by a tap alone. That tap now raises a sheet rather than the bar, and the difference is that a sheet is up only while a question is on screen — the bar was raised by a long press and stayed, so it was a password box sitting over the list whether or not anything was being asked. Dismissing it empties the box, which is not tidiness either: a secret left behind would satisfy the emptiness check that decides whether to raise the sheet at all, so the next tap would dial with somebody else's password. The pencil moving into that bar takes the host editor with it. It was a card in the list's own row, under the search box and the sync line — twenty controls sharing a screen with two rows of chrome about the list it had replaced. It is a page now, and PhoneShell stands all four of its rows down for it, which is what "opens with all the options" means at 360dp. That needed a second subscription in that control: two of its flags are questions about the vault rather than about the shell, and the shell does not forward the vault's notifications. The ticks are held as entity ids rather than as rows, and written back onto the rows after every reload. Every row object in the list is replaced on every filter keystroke and every synchronisation pass, so a set of rows would empty itself once a minute under somebody choosing what to do with eleven machines. Ids that no longer resolve are dropped, so a colleague's deletion arriving mid-selection leaves a count that matches what is on screen. One caller had to change with it. ConnectToRecent opened the pane about a host, which was the desktop's drawer and the phone's card; the phone's answer is now a tick, and nothing on that list means "selected" any more — so arriving with the host merely selected would be arriving at a screen with nothing to press. Both are raised together, and the one the head in front of the user does not draw is inert.	2026-08-06 09:15:37 +02:00
jaap-jan	69858f82d1	Merge branch 'claude/vault-key-sync-sharing-d098aa'	2026-08-06 07:39:32 +02:00
jaap-jan	185790fb14	Let a key move to another vault, and ask whether it goes with the host ... Keys sync and keys are shared: SshKey is in the sync registry on both sides, the material rides in the sealed payload, and every generation of the vault key is wrapped to a new member. What was missing was the way in. Hosts and groups could move between vaults and keychain items could not, so a key typed into a personal vault before the team existed stayed there for good — and moving a host into the team's vault left it authenticating with something nobody else in that vault can read. The code said so and could do nothing about it: "the answer is usually to put a copy of that key in the destination vault", which meant pasting the private half into a second item and deleting the first. A private key on a clipboard, and two items nobody can tell apart afterwards. MoveAsync already existed on the generic repository and is now exposed for keys and passwords as it is for hosts and groups. What had to be built around it is the re-aim. An item re-sealed under another vault's key lands with an id of that vault's making, so every host bound to the old one and every group lending it as a default is left naming a tombstone — and a host bound to something its vault no longer holds refuses to connect rather than falling back to a typed password. A move without the re-aim would look like a success and break every machine on that key. It runs over every vault this session can write to, because a binding resolves across all of them, and it counts what it could not rewrite: an item from a newer client, or one in a vault this account may only read. Those are said in the sentence afterwards rather than swallowed. The host's move asks the question rather than deciding it. A binding resolves across vaults, so the moved host goes on working for the person who moved it whichever way this is answered; it is the colleagues they have just joined who hold one vault's key and cannot connect with a host whose key stayed behind. Unticked, and it stays that way on purpose: moving a key into a team's vault hands it to everybody holding that key, and this design does not default anybody into a disclosure. Under the box is the count of everything else that authenticates with that key, because a key twenty machines use is a different decision from one nothing else touches, and neither number is visible from the panel otherwise. The question is answered against the vault in the picker, so choosing a different destination re-asks it and a key already in the destination offers nothing. One thing fixed on the way. A host that inherited its key from its group arrived in the destination naming nothing at all — the group belongs to the vault it left — so a machine that connected before the move refused after it, with no sentence anywhere saying why. The resolved binding is now written onto the host as it crosses, and the stranded-binding warning reads the resolved binding too, which is the case where somebody is least likely to know a key is involved. MOVE is on both heads, for keys and passwords only: a tag, a bucket and a pin are read from the active vault alone, so "another vault" is not a question any of them has. Four tests cover the move and its re-aim, the host's move with the key brought and without it, and the inherited binding.	2026-08-06 07:39:15 +02:00
jaap-jan	3d9ed03b09	Let a snippet be shared to a vault, the way a host already can ... A snippet was a first-class vault item everywhere except where it mattered: the crypto, the sync, the server table and every registry already treated it exactly as they treat a host, and the screen read it out of the active vault alone. So the one command a team most obviously wants to hold in common — the incantation somebody worked out once and everybody else retypes — was the only item kind that could not leave the machine that wrote it. The read is the half that had to come first, and it is why this is not simply a MoveAsync. ReloadSnippetsAsync now lists every readable vault rather than the active one, in the shape ReloadHostsAsync and ReloadKeysAsync already use: the vault new items go into first, then by vault name, then by label, with a badge on the row only where there is more than one vault to tell apart. Without that, a snippet moved into a team vault would have disappeared from the very screen that moved it, and one a colleague wrote there would never have arrived at all — sharing would have looked like losing. Three writes were pinned to the active vault and each one broke differently once the list spanned several. The delete tombstoned in the wrong vault, which tombstones nothing and leaves the snippet on screen. The save is the bad one: an update sent to the active vault creates a second snippet there and leaves the team original untouched, so the person editing sees their fix and nobody else ever does. That is a fork with no symptom, which is why the vault is now a parameter and the screen latches it when the editor opens — the chosen vault for a new snippet, the row own vault for an existing one — rather than reading it back off a selection that can move under a half-typed form. VaultViewModel has carried editingHostVaultId for the same reason since hosts crossed vaults. Two controls rather than one, and that is the same line the host pane draws. The editor asks which vault a new snippet is filed into; MOVE re-seals an existing one under another key and tombstones the first. Putting the second inside the first would let somebody correcting a typo hand a command to a team by leaving a picker where they found it, so the picker is not drawn for an existing snippet at all. Both live on SnippetsViewModel rather than VaultViewModel because this screen owns its editor, unlike the host drawer; the writing they ask for is still the vault. A snippet crosses whole, which is the one way this is simpler than the host it copies. A host leaves its group and its tags behind because both are items of the vault it came from and would dangle for everybody in the destination. A snippet is a label, a command and a note, and none of them points at anything — so there is nothing to strip, nothing to report as left behind, and what the copy says instead is the thing that is actually at stake: who can read the command afterwards. For a command that may carry a hostname or a path, that is the whole decision. Two judgement calls worth finding later. A hidden vault now hides its snippets, filtered in the screen projection rather than in VaultViewModel.Snippets, which is the rule keys and passwords already follow: the list stays whole so nothing that resolves against it breaks, and the projection is what a preference about reading gets to change. And the nav rail count is left spanning vaults unfiltered, because Vault.Hosts.Count beside it is unfiltered too — filtering one of the four would make the rail disagree with itself. Four flow tests in VaultSharingTests, beside the host ones they mirror: the move re-seals with a new id and carries the runs-on-insert flag across, the move with nowhere to go refuses rather than opening an empty picker, the editor files into the vault chosen on it, and the edit of a shared snippet goes back to its own vault instead of forking. That last one is the regression the latch exists for and the only one whose absence has no visible symptom. Plus a layout test with the move panel open, since that paragraph wraps in a 300-pixel column and the desktop pane it lands in is measured. The whole suite passes: 1660 tests, none failing.	2026-08-06 07:39:03 +02:00
jaap-jan	ca7fee2358	Start the confirmation Android hands back, so an update can install ... Pressing INSTALL closed the application, installed nothing and said nothing. That is two independent faults in one method, either of which breaks it on its own, and they hid each other: the first kills the process before the second can be observed, and the second is silent by construction. The pending intent handed to commit was implicit — an action string with no component behind it. A mutable pending intent may not wrap one of those from API 34, and this head targets 36, so every current phone threw IllegalArgumentException before commit was reached. Nothing caught it, so it left the command handler, passed the dispatcher and took the process with it. That is the closing. Below 34, where it did not throw, it still installed nothing. An application holding REQUEST_INSTALL_PACKAGES rather than the privileged INSTALL_PACKAGES gets no verdict back from a commit: what the platform answers first is STATUS_PENDING_USER_ACTION, carrying the activity that draws the dialogue in EXTRA_INTENT for the application to start. Android does not draw it on its own. The comment here asserted the opposite — that a pending intent is required whether or not anything listens, and that nothing needed to — so no receiver was ever written, and the session was written, committed and left staged forever. So there is a receiver now, not exported because the only sender is this application's own commit, and the intent naming it is explicit, which is the same change that stops the throw. Sessions are abandoned when anything fails, since one created and neither committed nor abandoned stays staged against a per-application cap — a repeating fault would have started failing at CreateSession instead, which is the same bug wearing a completely unrelated face. The reporting is the part worth keeping even after the cause is gone. Where applying ends the process an exception has nowhere to go; where it does not, which is this head's whole shape, it goes out through the dispatcher. RestartNowAsync now answers the way CheckNowAsync already did, and the regression test asserts the absence of a throw rather than the presence of one. ADR 0014 rule 6 gets the correction in place: "asks Android to ask" is one step longer than it reads. Check 17.5 needed no rewording — it asks for the installer appearing by name, which is exactly the thing that never happened — so what it gets instead is the two symptoms named, because both present as a dead button. It is the only thing in the project that can catch either, and it plainly was never run against a real pair of builds. Note for whoever takes the next nightly: a broken updater cannot install its own fix. The phone is running the code this commit replaces, so the first build carrying it has to be sideloaded by hand; the ones after that install normally. Compile-verified and manifest-verified — the receiver reaches the generated manifest — and 321 tests pass. Not run on a device, which is what 17.5 is for.	2026-08-05 22:31:33 +02:00
jaap-jan	dc1ebf6afa	Let the recovery code be copied, and give the phone a clipboard to copy to ... Both screens had made the code selectable and both said why: a person who cannot get it out of the box photographs the screen, and a screenshot is a worse home for it than a clipboard. This finishes that argument. Selecting 64 characters of letter-spaced monospace with a thumb is the version of "possible" people give up on halfway — and on the phone the screen blocks screenshots, so the honest remaining options were retyping it or losing it. It is the one secret this application deliberately offers to a clipboard, and the contrast with the keychain's copy is the whole argument rather than an inconsistency. There, copying the private half is refused outright, because installing a key means pasting the public one and the private one has no business leaving the vault. Here there is no better route: the code exists for one screen, is stored nowhere, and has to reach a password manager. The clipboard is the intended destination rather than a way round the design. The sentence afterwards matters as much as the copy, and is asserted: a clipboard is a staging post, this screen is the only place the code exists, and the next thing copied replaces it. Somebody who copies and does nothing has not saved it. The phone had no clipboard delegate at all — the desktop passed one and this head passed null — so COPY PUBLIC KEY on the keychain answered "this machine has no clipboard" on a device that plainly has one. Nothing about that was platform shaped: Android has a clipboard and Avalonia surfaces it through the same TopLevel. Wiring it fixes that copy too. The test fixture built its shell without a clipboard, which modelled the bug rather than the product, so it has one now and the public-key test asserts what lands there instead of the refusal. The refusal keeps its own test, on a shell built without one, because the view model reads the delegate's absence rather than an empty result — and because a button that silently does nothing on this screen is worse than one that refuses.	2026-08-05 18:14:34 +02:00
jaap-jan	ca07d63585	Offer to bring the keys an ssh_config points at ... An import that recorded a key path and left every host asking for a password was an import whose result did not connect. The answer to that was a manual paste per key, which is the sort of thing people do once and then stop importing. So there is a tick, and it starts off. With it off nothing changes: an IdentityFile becomes a note and the host asks for a password. With it on, IMPORT reads each host's first IdentityFile out of ~/.ssh, stores it in the vault encrypted like any other key, and binds the host to it. Three things about how it is drawn are load-bearing rather than tidy. It is a default nobody arrives at by accident. The sentence beside it names the directory rather than saying "your keys", because that is what somebody is agreeing to. And nothing is read during SCAN — tick it, read what it says, untick it, and no private key has been opened. This is the only place the application opens key material out of a directory the user did not point at file by file, and the whole of what makes that acceptable is that it took a deliberate press. One vault key per file, however many entries named it: an ssh_config pointing twelve hosts at one id_ed25519 is the ordinary shape, and twelve copies would be twelve things to rotate and eleven to forget. A file whose material is already in the keychain is bound to rather than stored again, which is what makes running the import twice harmless. What cannot be read off a disk is a passphrase, so a protected key arrives without one — and the report under the button names those files rather than leaving a host to fail at connect time with a message about a malformed key. Telling them apart means decoding for OpenSSH's own container, whose cipher name is the first field inside the base64 rather than anything in the armour, and that is the format ssh-keygen has written by default for years. The 88 base64 characters it decodes need 66 bytes, not 64: with the smaller span every protected key came back unprotected, which the tests now pin. A path that is not on this machine leaves its host imported and unbound, exactly as it would have been with the tick off, and is named in the same report. A config carried from another machine is the ordinary case, not an error.	2026-08-05 08:58:28 +02:00
jaap-jan	746711da9d	Let a tap on the phone's host list mean connect ... Choosing a machine raised the connect bar over the bottom of the list: a password box, CONNECT, EDIT, MOVE and DELETE. Five controls in the way of the one thing a tap on a machine's name obviously means. So the gestures split. A tap connects. A long press raises the bar, with all five. The pencil in the phone's header — its only persistent chrome — edits whichever host is chosen, which is the one of the five common enough to be worth a control that is always in the same place. The flag doing it is the desktop's own IsHostPaneOpen rather than a second one. That head made exactly this move when a selection stopped opening its drawer, and the question both are asking is "has somebody asked about this host" — answering it twice is how two heads come to disagree about what a selection means. One tap cannot finish: a host that authenticates with a typed password has nowhere on a list to be given one. That tap raises the bar with the box in it and says so, and a second tap with the box filled in connects. The branch is in the view model rather than in the head, because "can this machine be reached without asking for anything" is the same question the bar's own password box answers, and a copy of it in a view would be a second reading of a binding chain that has one. Two mechanics worth knowing. Avalonia raises Tapped on release whatever the press lasted, so a long press would open the bar and then connect — one touch firing both gestures — which is why HostsScreen tracks the hold and swallows the tap it precedes. And Holding only fires once IsHoldingEnabled is set, so that and the handler are attached together rather than one in markup and one in code. ConnectToRecent now opens the pane rather than selecting the row. On the phone it has to: a selection alone raises nothing now, so going back to a recent machine would land on a screen with nothing to press.	2026-08-05 08:43:33 +02:00
jaap-jan	69bc9e270b	Let a team be joined only by somebody who is already here ... An invitation decided access from an assertion about an address. Everything else in this model decides it from something a person did — an admin naming an account, a key holder wrapping a vault key to a key they verified — and this was the one place a token's email claim was the thing that let somebody in. It was guarded as tightly as that can be guarded: the claim was refused outright on an unverified or absent `email_verified`, with no setting to relax it. But the guard and the risk were the same shape. The whole defence was one boolean sent by a system the deployment does not control. So `POST /teams/{id}/members` is the only way in, and an address with no account is refused with `no-such-account` — which is now the end of the road rather than the signal to invite. Both clients say the remedy: that person signs in here once, which is what creates the account, and then they can be added. The desktop leaves the address in the box, because a message telling you to come back later is one you act on later. Gone with it: the `team_invitation` table, the claim hook in the sign-in path, and `Oidc:EmailVerifiedClaim`, which that hook was the only reader of. Nothing in the server now reads the email claim to decide anything. Pending invitations are dropped rather than converted. Converting one would mean creating a membership because an address matched, which is the property being removed — and an invitation to an address that did have an account here had already been claimed by the hourly sweep, so what is left is offers to people who never arrived. Two tests carry the property rather than the feature: the endpoint inventory asserts the three routes are absent, and the API suite adds an address that has no account, watches the refusal, then signs that address in and checks it joined nothing. Without the second half, a server that merely renamed the deferred path would pass.	2026-08-05 08:28:57 +02:00
jaap-jan	b4a6c19ac1	Let the phone replace itself, and give CI a channel it may sign ... The Android head had no updater and no release path, and the two are one problem: Android refuses an update signed by a different key, and CI generates a fresh debug key in every container. An APK released from a workflow could be installed once and never updated again — each new one an uninstall, which on this product means losing the cache, the outbox and the device key. So there are two channels, and they are two applications because the platform gives no third option. dev.dodotech.dodossh is cut from a v* tag by a person running scripts/release-android.ps1 with the key ADR 0011 rule 1 keeps off runners. dev.dodotech.dodossh.nightly is cut from main by CI and signed with a keystore committed here in the open — a key everybody has cannot be stolen and grants nothing by being held, which is why putting it in CI does not touch the rule. Neither can update the other, by construction. See ADR 0014. The android job assumed an image with a JDK and an Android SDK on it, which is what a GitHub runner is and what this project's is not. It now installs a JDK, fetches Google's command-line tools, accepts the licences and installs API 36 — each a no-op where it is already satisfied, and each cached by the persistent runner's own disk rather than by an action that would move a quarter of a gigabyte to rebuild a directory that never left. The client reads a small JSON manifest beside the APK, the counterpart of releases.win.json, and compares Android's versionCode rather than a version name: that integer is what the platform itself uses to accept or refuse an install, so comparing anything else would offer updates the phone then rejects. It fetches, and then asks Android to ask — the system draws its own confirmation, and from API 26 will not draw even that until unknown sources is on for this application. IUpdateChannel gained ApplyingEndsTheProcess. On Windows applying replaces the files and restarts, so the shell disposes the vault first and that is what zeroes the keys. On the phone the install is a request and the answer may be no, so disposing first would answer "not now" with a locked keychain and every shell closed — a punishment for declining an update. Two measured bugs found on the way, both older than this work and both invisible to a -getProperty check. ApplicationDisplayVersion is read by the Android targets in a top-level PropertyGroup, so the target setting it from MinVer ran after the only thing that reads it: every APK ever built here said versionName 1.0.0. And nothing found so far varies the launcher name per channel — four mechanisms tried, all of them recorded in platform-flags, none of them reaching the label the launcher shows. The two channels share an icon name for now and are told apart by package name, version, and what the preferences screen says.	2026-08-04 21:46:01 +02:00
jaap-jan	50fa6fba38	Let the phone delete a host, and move or remove a group ... The desktop gained three things the phone did not follow: moving a group to another vault, the second question asking whether a group's deletion takes its hosts with it, and — since long before either — deleting a host at all. What that left was a head whose v3 + can fill a keychain and whose editors can correct one, with no way to empty either. The commands could not simply be bound. DeleteGroup and MoveGroup aim at GroupTarget, which is the selected card or the open group, and the phone has neither: its list draws headings, and a heading's selection deliberately bounces back to the host. Called bare on that head they would have returned having done nothing — a DELETE that appears to have been pressed and has not. Both now take the row and fall back to GroupTarget for the desktop's menu, and ConfirmMoveGroupAsync resolves from the panel's own movingGroupId rather than from the selection, which is also the honester answer on the desktop: what moves is the shelf the panel was opened on. The heading's pencil became a menu. Three icons after a chevron, a name, a vault badge and a count is what would be left of the name at 360dp, so the ⋯ raises the add sheet's shape carrying Edit, Move to another vault, a rule, and Delete — the desktop's card menu, in the one idiom this screen already has. It does not carry Open: the desktop's grid holds one level of the group tree and this list holds all of it flattened, so there is nowhere to open a group into. DELETE under a host sits on a row of its own beneath EDIT and MOVE rather than beside them. A phone has no hover and no tooltip, so where a thumb lands is the only thing separating a destructive control from an ordinary one. Both questions take the controls that asked them — ShowsConnectControls, which is the phone's half of the rule ShowsHostPaneActions already carries for the desktop's drawer — so DELETE cannot be pressed a second time underneath its own confirmation. Preferences gained the running version, and the sentence saying this head does not replace itself and that no DodoSSH server will ever offer one. It reads Updates.CurrentVersion off the same view model the desktop's UPDATES section does, over the null channel that reports itself unsupported. Nothing was needed for the realtime push: it is composed in ServerConnection, which both heads use. Seven tests, all phone-shaped — a group acted on with nothing selected, the menu waved away leaving nothing armed, the ungrouped heading raising none, and the bar's three states. The rectangles remain unmeasurable for the reason phase 8 gives; the checks for them are 8.10 to 8.13 and 13.6.	2026-08-04 19:58:10 +02:00
jaap-jan	3ead865f01	Merge branch 'main' into the desktop updater, and give way on two numbers ... Main landed a realtime push feature while this branch was building the updater, and the two collided in three places. Every one of them resolves the same way: main got there first, so this branch moves. **Two ADRs were both numbered 0012.** Main's is realtime push; this one is now [ADR 0013](docs/adr/0013-desktop-distribution-and-updates.md). Git did not call this a conflict — the filenames differ — so it would have merged quietly and left the directory with two 0012s and every cross-reference ambiguous. Renumbered here along with the nine places that point at it. **Two manual-check phases were both numbered 15**, and that one git did catch. Main's "Changes that arrive without a timer" keeps 15; installing and updating the desktop client becomes Phase 16, with its checks and every reference to them renumbered. The file's own rule is that a number is for life, which is exactly why the one that had not been pushed is the one that gives way. **The merge rewrote several files with CRLF**, and `.editorconfig` asks for LF on everything except `*.ps1`. That is not cosmetic here: IDE0055 is an error and `EnforceCodeStyleInBuild` is on, so it failed the build on three lines of App.axaml.cs whose only change in this branch was an ADR number in a comment. Forty-six files normalised back to LF; the release script keeps CRLF, which is what `.gitattributes` and `.editorconfig` both already say for a PowerShell file. Nothing else conflicted. The updater does not touch the sync loop or the event stream, and the one file both sides edited heavily — MainWindowViewModel — merged without a hunk in common. Verified after merging: the solution restores locked and builds clean, and 304 shell, 100 layout, 54 session, 28 client-api and 25 contracts tests pass. The first two counts are higher than before the merge because main's own tests came with it and pass alongside these.	2026-08-04 17:52:57 +02:00