24 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	03c8e8589a	Keep downloads inside the folder they were sent to, never run a file opened for editing, and let a bucket upload be retried ... - A remote name went straight into Path.Combine. A POSIX name may hold backslashes, a colon or a drive letter, and an S3 key may hold "../", so a name chosen by whoever could write to the host decided where on this machine a download landed. LocalDirectory.ChildPath cleans the name and requires the resolved parent to be the target folder; every download path and EDIT use it, and a name that cannot be a file there is left on the host and reported. - EDIT handed the copy to the shell's default action, which for .bat, .hta, .js and friends is to run it. LocalEditor opens such a file with its own "edit" verb or Notepad on Windows and `open -t` on macOS, and refuses a .desktop launcher on Linux. - A failed bucket upload leaves its part object, and a retry asked for an offset no bucket accepts, so the row could never finish. IRemoteFileStore.CanWriteFromAnOffset is false for buckets and the queue starts those over. - The SFTP host picker re-found its selection from the empty moment of every vault reload and landed on the first host once a minute; the chosen host is now remembered, and a typed password is only sent to the host it was typed for.	2026-10-02 13:16:30 +02:00
jaap-jan	4c7f47c026	Refuse a pinned host that answers with a key of another type, rather than asking whether to trust it ... Pins are stored per algorithm, so an endpoint pinned for ssh-ed25519 that was answered with only an ECDSA or RSA key found no pin and raised SshHostKeyUnknownException: the first-use question, where a pin exists to produce a hard refusal. Anybody in the middle needed nothing more than a key of a different type. The connection factory now reads every pin for the endpoint before the handshake, offers the pinned algorithms first so a server that still holds its pinned key negotiates it, and in the gate accepts a key under an unpinned algorithm only when its fingerprint matches one of the endpoint's pins (one RSA key signs as rsa-sha2-256 and rsa-sha2-512). Anything else is a mismatch. IKnownHostStore gains FindForEndpointAsync for this.	2026-10-02 13:16:30 +02:00
jaap-jan	f05deb4fbc	Add port forwarding: local, remote and dynamic, per terminal session ... A host can now carry port forwards (-L, -R, -D), saved inside its encrypted payload as RelayTicketRequest.PortForwardId already assumed, so they sync and merge per forward like tags and pinned paths. The host schema moves to version 8 only for hosts that carry forwards. ISshConnection gains StartForwardAsync over SSH.NET's forwarded ports. Every listener binds loopback and there is no bind-address field: a forward is something any member of a shared keychain can edit. A remote forward's target is resolved here, IPv4 first, rather than by SSH.NET's constructor, which takes the first DNS answer and can send ::1. Forwards start with every terminal opened to the host and stop with its connection; a reconnect starts them again. The session sidebar lists them with state, failure reason and an on/off switch, the status bar counts the listening ones, and the host editor and detail pane gain a PORT FORWARDS section. A forward that cannot start fails alone. The phone does not start forwards yet: it has no surface showing what is listening, and its More screen now says so. No byte counts, since SSH.NET keeps none.	2026-09-28 20:47:02 +02:00
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
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
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	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	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	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	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	82966af37b	Let a connection be reached through a proxy on this machine's loopback ... Step 1 of docs/reaching-a-host-you-cannot-dial.md, and it is not the step that document said it was. SshConnectionRequest carries an optional SshLoopbackProxy and BuildConnectionInfo hands SSH.NET its proxy ConnectionInfo when there is one. Nothing passes one yet: the callers are jump hosts and the relay, which are steps 2 and 3. ◆ THE BRIDGE WAS THE WRONG FIRST STEP, AND BUILDING IT WOULD HAVE BEEN THE MISTAKE THIS DOCUMENT IS ABOUT. ADR 0004 says the relay's loopback bridge "also provides ProxyJump via a SOCKS5 dynamic forward — one mechanism, two features", and the plan took that to mean the bridge was the shared foundation. It is not: ForwardedPortDynamic *is* the listener for a jump host — SSH.NET accepts on it, speaks SOCKS5 on it and tunnels through the bastion — so nothing is left for a bridge of ours to do on that path. The relay is the case with no SshClient to hang a forward off, so it is the bridge's only consumer, and the bridge belongs in the commit that uses it. What the two actually share is one level down and a tenth of the size: being told to reach a target through a loopback proxy while staying about the target. That is what this is. Three properties, one test each. A port and nothing else, so a proxy anywhere but loopback cannot be expressed. The failure that shape rules out is an open SOCKS proxy on the user's network for the life of a shell, which nothing would report — so it is made unrepresentable rather than validated, on the same grounds AuthenticationChoice carries a kind. SOCKS5 rather than a dumb pipe, which is what keeps host key pinning honest. The target's own name and port stay in the request, travel to the proxy in the CONNECT, and are what the gate pins — so a machine reached through a bastion is pinned under its own name instead of under 127.0.0.1 on whatever ephemeral port that day's forward got, which is not an identity at all. A pipe would have meant handing SSH.NET a stand-in and remembering everywhere else that it was one. And a proxy that is not listening fails as a connection error rather than as an unknown host key. The gate turns "no host key seen" into a fingerprint prompt, and a connection that never reached a server has seen none either; the prompt would offer to fix the wrong thing, with no fingerprint to show. TWO THINGS THE TESTS MEASURED RATHER THAN ASSUMED, both found by the first run failing. The target is resolved at the *bastion*, not here — a SOCKS CONNECT names it and the far end looks it up. So the test asks for localhost:2222, the address inside the container, and the published port this host would use means nothing there. That is not a quirk of the fixture; it is what ProxyJump means, and it is why an ssh_config writes the target's internal address beside its jump host. Getting it wrong is a SOCKS "general failure" that names neither end. And the test server refuses forwarding. linuxserver/openssh-server ships AllowTcpForwarding no, which a dynamic forward does not notice — opening one asks the server nothing — so every connection through it is refused at channel-open and reported as the same general failure. The fixture patches it and HUPs sshd. There are two sshd_config files in that image and the running server uses /config/sshd/sshd_config; the first attempt patched /etc/ssh/sshd_config, which is the one a search finds first, changed the text and nothing else, and left the failure exactly where it was. VERIFIED. Build clean with no new warnings, 85 tests in Client.Ssh.Tests against the real sshd, and the solution builds. The proxy test was seen to fail — proxy.Port + 1 in BuildConnectionInfo — and seen green again. An earlier mutation attempt did not compile, and the log said 85 passing because the run never started and the previous log was still on disk; the second attempt deletes the log first, which is worth copying whenever a mutation "passes". dotnet format reports one pre-existing IDE1006 in DodoSSH.Api/Features/Events/EventsEndpoint.cs, in a project nothing here touches. Left alone.	2026-08-07 13:48:15 +02:00
jaap-jan	6728a0a597	Let the desktop client replace itself, and give the repository one version ... Packaging for Windows, and the updater that only exists once something is packaged. Velopack, win-x64, fed from the project's own forge — never from the deployment a client signs in to, which is ADR 0011 rule 2 carried over unchanged and is why the feed address is a constant in the code rather than a setting. See docs/adr/0012-desktop-distribution-and-updates.md. **Nothing is ever installed while somebody is using it.** A newer build is found on a six-hourly pass, downloaded in the background, and then waits — for a restart the user presses, or for the next launch they were going to do anyway. That is a policy rather than caution: this application argues at length that locking keeps shells running, because a lock that destroyed work would stop being used, and a restart does not keep them. Having taught that, it owes the user the choice at the one moment it stops being true, and the sentence saying so counts the shells it would close. **The version is now derived from the v* tag**, by MinVer, for everything. There was no version before this — no property anywhere, so every assembly reported the SDK's 1.0.0 and the API served that string as its serverVersion to every client that asked. The tag was already the version of record for the container image; this makes it the version of record full stop. MinVer's failure mode is answering plausibly rather than failing, and here a wrong version is a client that never updates, so it is guarded twice: fetch-depth 0 on every checkout, and a step that fails a tag build when the tag and the computed version disagree. **The pack id is DodoSSH.Desktop and not DodoSSH**, which is the one decision here that would have destroyed data. Velopack installs to %LOCALAPPDATA%\<packId> and removes that whole directory on uninstall, and %LOCALAPPDATA%\DodoSSH is where ClientPaths keeps the encrypted cache, the outbox of changes not yet pushed, and the device key. The obvious id would have had the uninstaller silently delete work the server has never seen — the thing the application refuses to do without a counted confirmation. Velopack's own advice to move user data to roaming %APPDATA% is declined for the reason ClientPaths already gives. **Releases are cut by a person, and CI gains no job that could.** The tempting argument is that a forge write token is not a signing key. It does not survive contact with what the token does: Velopack clients trust their feed and do not verify a package signature when they apply one, so whoever can write a release can ship an update every install runs. That is the capability ADR 0011 rule 1 puts on a machine which is not a runner, reached through a different door. The mechanical objection — vpk needs Windows and the runners are Linux — is the smaller of the two and is recorded beside it, because somebody will fix one and believe they are done. Unsigned for now, deliberately and with the cost stated where a user reads it: SmartScreen warns once per person, on Setup.exe, because Mark-of-the-Web is applied by the browser that downloaded it. In-app updates are fetched by the application and applied from a local file, and never trip it. The banner is a fourth row of the window rather than an overlay. Anything drawn in the terminal's rectangle is sliced by the native child window that composites above it — the defect this window has shipped once — and a sibling row is the arrangement TitleBar and StatusBar already prove works. ---- Three defects surfaced on the way, none of them in the feature being built. **A settings key absent from the file came back as the CLR default, not the declared one.** The JSON source generator builds a record through a synthesised parameterised constructor and assigns every property from its argument array, so a property initializer runs and is then overwritten by a default for anything the file did not contain. A settings.json of {} read back a font size of 0, clamped up to the 8px floor rather than the 13px the renderer draws at. It could not bite while there was one setting, because that setting was written on every save and so was never absent; adding a second would have turned automatic update checks off for every existing profile, silently, the opposite of the documented default. Reflection-based deserialisation of the same JSON answers correctly, which is why every way of checking it by hand agrees except the one that ships. The defaults now live on the constructor parameters, which is the only place the generator reads them from. **Declaring a RuntimeIdentifier on the desktop head broke the server's image build.** It is the obvious way to let a self-contained publish restore under locked mode, and it writes a net10.0/win-x64 target into the lock file of every project the head references transitively — including DodoSSH.Contracts and DodoSSH.Crypto, which the API builds too. The Dockerfile restores those with no RID and fails NU1004. Found by running docker build rather than by reading. The RID stays out of the committed state; the two commands that need one ask for it unlocked, and the release script puts the lock files back. **A Docker ARG named VERSION silently sets MSBuild's Version.** An ARG is an environment variable for the rest of the stage, MSBuild reads environment variables as properties, and property names are case-insensitive. With the workflow passing main-<short sha> on a main build the publish died with NETSDK1018 pointing at DodoSSH.Contracts, a project nobody had touched. The build stage's argument is ASSEMBLY_VERSION now, empty except on a tag build. All three are in docs/platform-flags.md, which is where the next person will look. ---- Verified: the whole solution builds and restores locked; 289 shell, 93 layout and 54 session tests pass, including the regression test for the settings defect and a measurement of the banner at the window's minimum width. vpk pack runs end to end and reports "Verified VelopackApp.Run()" against Program.Main. The API image builds correctly both as a main build and as a tag build, carrying 1.0.0 and 0.1.0 respectively. Not verified, and it needs a published release to be: installing, updating and uninstalling on a real machine. That is Phase 15 of docs/manual-checks.md, and the pack id and the WebView2 profile fix are reasoned and commented but only proved by walking it. Two things to watch at the first upload — the reverse proxy's body-size limit for a 64 MB asset, and whether vpk upload gitea is happy with Gitea 1.27.1.	2026-08-04 17:04:41 +02:00
jaap-janandClaude Opus 5	8a568117df	Give the API an image, and unbreak the restore that had to run first ... registry-docker.dodotech.cloud/dodotech/dodossh-api, built and pushed by a third ci job that needs the first. Gating on the tests costs a few minutes on every main commit and buys the only thing worth having here: an image is not an artefact somebody inspects before using it, so a red commit must not be able to produce one. Pull requests build the image and stop, which is where a broken Dockerfile should be found. Tags are :sha-<short> on every build, :main on main, and for a v* tag :1.2.3, :1.2 and :latest — the last two only when the version has no prerelease suffix, since v1.3.0-rc1 sorts above v1.2.9 and would otherwise walk :latest onto somebody's server. Only sha- is immutable, and it is the one to pin a deployment to. No docker/* actions. The build is single-architecture, so it needs the daemon this runner already has for the Testcontainers suites and nothing else — no buildx, no QEMU, and no third-party action whose SHA has to be audited and re-pinned. Step outputs and secrets reach the shell through env rather than ${{ }} interpolation, because a git tag may contain a semicolon and interpolation is textual substitution performed before the shell parses the line. The image is chiseled: no shell, no package manager, uid 1654. Affordable because Directory.Build.props already sets InvariantGlobalization, so the ICU and tzdata a normal base carries are exactly what this product decided not to use. The cost is stated in the Dockerfile rather than hidden — there is no HEALTHCHECK, because there is nothing to run one with, and /healthz/ready is anonymous precisely so the orchestrator can ask instead. Nothing migrates the schema from inside the container either; readiness fails while a migration is pending and names it, which is the design. And the restore that all of this depends on did not work. 7a3a521 committed lock files carrying a net10.0/android-arm64 section into fourteen projects — written there by the Android head's -p:RuntimeIdentifier=android-arm64 packaging build, which restores the shared projects with a RID and updates their lock files as a side effect. Any restore without that RID then fails NU1004 in locked mode, which is every other build there is: `dotnet restore DodoSSH.slnx --locked-mode` has been failing for eleven projects on a clean checkout of main since that commit. The sections are removed here and nothing else changed — deletions only, ILLink.Tasks stays at 10.0.10. Verified: the solution restores in locked mode, the image builds, and it runs. /healthz/live answers 200 and /healthz/ready answers 503 naming the database it cannot reach, from a 67 MB image as uid 1654, configured entirely through DODOSSH_-prefixed variables. The Android head's own lock file still carries the RID and is untouched, because that job restores it separately and is outside DodoSSH.slnx. Whether its packaging step re-dirties these fourteen on every CI run is worth a look; it is the same mechanism. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 13:40:12 +02:00
jaap-jan	7a3a521c59	Give the phone the rest of its screens, and a way in ... All seven screens of the design, plus the two it does not draw because it starts at an enrolled phone: naming a server, and choosing a passphrase. The five states docs/android-port.md worried about losing at 360dp are all here and none of them softened. The changed-key refusal is a full-screen panel rather than a bottom sheet, because a sheet is swipe-to-dismiss by convention and that screen must have no way forward. The recovery code raises FLAG_SECURE for its own state and lowers it afterwards, so the sentence about screenshots is true rather than decorative. The delete confirmations keep their counts and replace the row in place. Signing in works, and the seam it needed is worth more than the implementation: IAuthorizationCallback now sits between OidcClient and the loopback listener, so the two heads differ in where the response arrives and in nothing else. PKCE, the state check, discovery, the token exchange and the key binding stay one implementation — a second OIDC client would be a second place for a security bug to live. The phone registers a private-use scheme with the system rather than binding a loopback port, which on a shared device any other app can do first. The accessory key row needed TerminalWorkspace.SendInputAsync: ordinary typing goes from the renderer straight down the socket, and there was no way in for the keys a software keyboard does not have. Ctrl latches, because one thumb cannot chord, and the latch is drawn — a modifier that is on and does not look on is how somebody sends ^L to a database prompt believing they typed an l. 597 client tests green, including two new ones for the input path and one for the terminal surface command. Nothing has run on a device.	2026-07-31 21:43:11 +02:00
jaap-jan	5cbda59a34	Merge branch 'main' into claude/host-management-ui-plan-7f20ab ... Seven files needed a hand. Most were two branches adding something in the same place, but three were one branch changing what the other had moved or renamed, and those are the ones worth reading. The shell keeps both new fields and both constructor lines: the connection recorder this branch built and the teams view model main did. Where main put a teams load inside OnScreenChanged, it now sits beside the logs refresh rather than inside RaiseSurfaceState — this branch extracted that notification block and it is called from two properties, so a screen-specific side effect in there would fire on every terminal switch as well. Main gave four row types a vault id and a vault name, and this branch had moved one of them — KnownHostRowViewModel — into its own file when the pinned keys became a screen. Git resolved that as "deleted here, modified there" and took the delete, which compiles as long as nobody looks: the moved copy still had the two-argument constructor and the call site had grown to four. Carried over by hand, along with the ordering the pins list now does on them. The status line's quiet rule was the subtle one. Main extracted it into IsWorthReporting; this branch had changed the same condition to read item counts rather than raw ones, because every user action queues a log entry a moment later and this machine reads its own entries back on the next pull. Take main's structure and the merge builds, passes, and silently restores a bug this branch existed partly to fix — every save's message overwritten a second after it appears. The method now reads PulledItems and PushedItems, with the reason in its remarks. Two conflicts were prose that had gone stale rather than code. The keychain screen's comment said team vaults are refused by the server's access service, which was true when it was written and is not now; main's replacement stands, in this branch's vocabulary. The design-gaps row for groups was claimed by both — real host groups here, per-vault headings there — and they are different things, so both rows stay and the difference is stated: a group is a shelf the user chose, a vault is who can read the item. One defect the tests found and the compiler could not. Generating a key opens the same editor as pasting one, but not through NewKey — so it never set the target vault main added, and a generated key was filed into whatever vault was edited last, or none. Both key-generation tests failed on it. Fixed where the editor opens, with the reason recorded there. One gap is left deliberately and is written down rather than half-built. Hosts, keys, credentials and pins are read across every vault this session holds a key for; groups are read from the active vault alone, so a host a teammate filed shows under UNGROUPED. Nothing is lost or misfiled — it is what the sidebar already shows for a group that has been deleted — but closing it needs a vault id on every group row for rename and delete, and a way to tell two vaults' identically-named groups apart under a layout with one heading per group. Both are worth doing and neither is a merge's business. It is in the remarks on ReloadGroupsAsync and in docs/design-import-gaps.md. dotnet build, dotnet test and dotnet format --verify-no-changes are all clean: 1282 tests, including the end-to-end suite against real containers.	2026-07-31 20:44:39 +02:00
jaap-jan	d07b336868	Free the terminal from the Hosts screen, and fill the room it left ... The WebView sat inside the Hosts grid, so navigating to Files or the keychain hid every open terminal and the strip that named them. A connection you had opened was invisible from four of the five screens. The window now has two surfaces rather than one: a nav rail that says which page you are on, and a terminal strip that is always there and switches the whole content area to a shell. Screen keeps meaning "which page" and never becomes a sixth kind of page, which is why this is two properties instead of one enum with a terminal member in it. Every screen lives inside one wrapper panel that collapses when a terminal is showing. That is not tidiness — the WebView hosts a Win32 child window that composites above everything Avalonia draws, so a screen left visible over its rectangle is a screen sliced in half, and this window has shipped that defect once already. One decision point, IsTerminalShowing, and a nested panel rather than five compound bindings nobody would remember to extend. The focus choreography is the part no test in this repo can see. Every reveal path now focuses in the same turn the WebView appeared, so all three of them post at DispatcherPriority.Loaded and let the native control re-push its bounds first. Going the other way had a real bug: the screen-changed branch called a bare Focus() where it had to release the keyboard from the native child, so switching from a terminal to Files silently ate the first keystrokes. Rare before this commit and the primary gesture after it. The tab strip grew a cross inside each tab, a plus that opens the quick-connect palette, and middle-click close. Nested buttons are correct here: Avalonia handles a left press on the cross and deliberately does not handle other buttons, which is exactly what lets middle-click bubble up from the cross as well as the tab. The test is PointerUpdateKind rather than IsMiddleButtonPressed, because the latter reports button state and is also true for a left press made while the middle button happens to be held. The handler is on the tab and not the strip, so the background closes nothing by construction. Plus opens the palette rather than a flyout, since a menu dropping into the WebView's rectangle may or may not composite above a child HWND and this repo does not make rendering claims it has not photographed. Everything a user reads now says keychain. The wire, the database and the cryptographic spec still say vault, deliberately: renaming those is a migration and a protocol change for a word. That split is written down rather than left to be rediscovered as an inconsistency. Four things that were squeezed into the keychain's category rail, or into nothing at all, now have screens. Pinned host keys get one, with fingerprints never truncated and a filter that matches them, because comparing what you have against what the operator published is the whole workflow; the approved date is read out of the item's UUIDv7 rather than added as a column, and says so, since it means first approval and not last use. Keys can be generated in the client, which needed the openssh-key-v1 container written by hand — there is no BCL or NSec helper, and the PKCS#8 route is unverified in the SSH library this uses. The armour carries no passphrase: encrypting it needs bcrypt_pbkdf, which is Blowfish with a swizzle, in a project whose crypto is otherwise entirely libsodium, for a protection the key's own remarks argue is redundant inside a vault. Generation fills the existing editor and stops, so SAVE stays the one thing that writes. ~/.ssh/config can be imported behind a preview that is ticked per row and writes nothing until the button; IdentityFile records the path and imports the key material only on an explicit opt-in, because reading somebody's private key into a vault is precisely the act this product exists to make deliberate. Match blocks and ProxyJump are reported rather than obeyed — one cannot be evaluated statically and the other has nothing behind it to route with, and a preview that implied otherwise would be worse than one that admits it. Files can be dragged in all four directions that are honestly available. Remote to Explorer does not ship and is not pretended to: the shell wants the bytes during the drop, which needs a virtual file and a native COM data object, outside what Avalonia offers. Note for the next person that Avalonia 12 replaced the drag model outright — DataObject and DataFormats are no-op stubs and IDataObject is not in the reference assembly, so every tutorial written for 11 does not compile here. Hosts can be grouped, flat and never nested. A parent id merged as a scalar lets two offline clients each re-parent A under B and B under A, producing a cycle inside an encrypted payload that no server can police and every reader would have to detect for ever. Membership lives in that payload rather than in the one plaintext concession ADR 0001 allows, whose test is that the relay cannot function without it — nothing on the server reads a group, so what plaintext would hand over is a clustering of the estate for nothing. The plaintext column reserved for it is dropped, provably always null, and the server now refuses a client that sends one; it was never populated, was copied on apply, and was not cleared on delete, so a group id would have outlived the host it described. Snippets insert through xterm rather than through the pump, because xterm is the only thing that knows whether the remote has bracketed paste on, and that is what makes a shell treat embedded newlines as text instead of as execute. The host process moves opaque bytes and never parses output, so it would have to guess, and guessing wrong runs every line. Running is off by default and the copy says the text goes into whatever is there — the terminal has no notion of being at a prompt, and may be in vi or at a password prompt with echo off, so the Enter the user presses themselves is the entire safety property. Connections and keychain changes are recorded as synced encrypted items, which is what makes them auditable by a team later and costs the server knowledge of connection rate and timing from row counts alone. ADR 0001 already concedes it cannot hide that class of metadata; the trade is now written into it rather than left implicit. A connection entry is written once, at close, which is what makes a synced log tractable: nothing to merge, one outbox row, no chance of colliding with itself. Live sessions come from memory, not from the log. The write is void by contract and posts to a bounded channel, because putting an encrypt-and-write on the teardown path of every session is how closing the application comes to take four seconds. A ticket opened before a lock still closes afterwards, since a shell outlives the vault. The activity log hooks the one generic repository every kind writes through, so it cannot miss a caller — which is also why the log kinds themselves declare they are not audited, or the first entry would write an entry about writing an entry. It records the names of the fields that changed and never their values; a log with an old password in it would be a plaintext credential store with no vault around it. Retention is 90 days or 5,000 entries, whichever bites first, pruned on the sync loop rather than on a second timer. That log traffic then broke the status line, which is worth recording because the fix is a shape and not a patch: background sync counted its own log rows as pushed items, so the quiet rule stopped being quiet and every action's message was overwritten a second later by a sync report. The report now separates log rows from user items and the rule reads the latter. S3 buckets appear as a remote in the file browser, behind the same interface an SFTP session implements, so the queue and both panes did not have to learn what they are talking to. Uploads go through a pipe, because the queue wants to write and the SDK wants to read; memory is then bounded by the part size instead of buffering a file to disk twice. Finally, the Windows device key store moved out of the session project, which was the one thing keeping it from being portable — everything else in it is platform-neutral, and a Windows CNG dependency in the middle of the vault code meant a second head could not reference it without dragging Windows along. The seam that made the move free was already there. docs/android-port.md is the audit behind that: what ports, what does not, in order of cost, the four decisions taken, and an inventory of every screen and state the interface has to carry, written so a design can be made from it directly. dotnet build, dotnet test and dotnet format --verify-no-changes are all clean: 1240 tests at zero warnings, including the end-to-end suite against real containers. The manual checks that headless Avalonia cannot make — the drag from Explorer, a generated key against a real host, twelve tabs at the minimum window width — are listed in docs/manual-checks.md and are still outstanding.	2026-07-31 20:30:05 +02:00
jaap-jan	03e902a2d2	Colour the host's file rows by what their mode says ... The remote pane's NAME column was blue for a directory and plain for everything else, and the PERMS column was faint whatever it said. Two colours now come off the mode, split across those two columns on purpose: NAME says what a row is, so a file with an execute bit is green there, and PERMS says what is notable about how it is set, so a file anyone may write to is amber over the characters that actually say so. Because the two never compete for one TextBlock, a world-writable executable shows both facts instead of one winning an argument. No new blue is spent, which is what App.axaml asks for: it reserves blue for a directory, a distinct scope, and calls it deliberately rare. Both are files only, and each exclusion is a wrong answer avoided rather than a case not got to. Every symbolic link is lrwxrwxrwx by convention and its mode governs nothing — what may be written is the target, whose mode an lstat listing never fetched — so amber there would fire on every link on the host. A world-writable directory is /tmp, made safe by a sticky bit PosixMode does not render, and warning about it would be warning about the half of the mode that is on screen while the half that answers the warning is not. And the execute bit on a directory means "may be searched", which is true of very nearly every directory a host has, so green there would paint the whole pane and mark nothing. The two questions read back the string PosixMode wrote rather than carrying its nine booleans through SftpEntry as well. That is the point rather than a shortcut: two representations of one fact is how a row ends up coloured for a bit the column beside it does not show. A mode of the wrong length answers false rather than throwing, since these decide a colour and a listing is not worth failing over one. The amber is Warn rather than WarnText, which is the muted amber a warning card writes its sentences in. At 9.5px against TextFaint that one is a shade rather than a signal, and a marker nobody notices is the same as no marker. The local pane is untouched, on the grounds it already gives for having no PERMS column at all: a POSIX mode is not a fact about a file on Windows, and colouring one there would invent exactly what the column declines to print. Twenty cases in RemotePathTests, which needs no container — the execute bit in any of the three triples rather than only the owner's, the others-write bit alone, a mode of the wrong length, and the file-only rule for both questions from all three kinds. dotnet format is clean and the app and layout suites pass at 109 and 35.	2026-07-31 12:17:56 +02:00
jaap-jan	04faef6597	Move files to and from a host over SFTP ... M2's file transfer, built bottom-up: an SFTP session on the SSH layer, a transfer queue in a project of its own, and the two-pane browser the design asked for replacing the screen that said it did not exist. Remote listings carry names, sizes, modification times and a real drwxr-xr-x — nothing in this repository could render a POSIX mode before — and the queue moves one file at a time with progress, throughput and resume. The design import assumed this would be an SFTP subsystem channel on ISshConnection, beside the shell on a transport that is already up. SSH.NET does not offer that: SftpClient derives from BaseClient and owns its own transport, and there is no supported way to hand it an SshClient's session. So file transfer opens a second authenticated connection, and it is named for that rather than dressed up as a channel — OpenSftpAsync is on ISftpSessionFactory, not on a connection. The difference is visible to a user: the host records a second login, and a host whose password is typed each time asks for it again on this screen. It goes through the same host key gate, the same pin and the same two refusals a shell does, so a fingerprint approved for a terminal is approved here and one approved here reaches the other machines with the next sync. docs/design-import-gaps.md is corrected, and marked as the one row where what shipped differs from what it predicted. Nothing is written at its final name until it is complete. Every transfer goes to a .dodossh-part file beside its destination and is renamed into place at the end, so an interrupted transfer can never be mistaken for a finished one — which matters most for what this screen is actually for, which is copying a build artefact onto a server and then running it. A destination that already exists is refused outright rather than overwritten: the queue has no way to ask, and silently replacing a file somebody's process is serving is the worse of the two failures. The remote pane has DELETE and MKDIR so that refusal is not a dead end. A test against the container pins the assumption underneath all of this — that SFTP's rename does not clobber. Resume works within a run of the application and not across a restart, and the limit is deliberate rather than unfinished. Nothing records which source wrote a part file, and resuming one on the strength of its name matching is how a corrupt artefact gets delivered with nothing reporting a failure; a part file found at startup is started over. Making it survive a restart needs the preferences store this client still has not got. The offset a resume starts at is the part file's own length rather than the transfer's recorded progress: a cancellation can land between a write completing and the counter moving, and only one of those two is a fact about the bytes that are there. The queue and its connection outlive a lock, as shells do. LockAsync already argues that locking must not destroy work in flight — it is what somebody does when they walk away from the machine, which is exactly when a long transfer is most likely to be running — so TransfersViewModel is created once and the vault is attached on unlock and detached on lock. What locking takes is the host list, and it has to: those rows carry decrypted secrets. DodoSSH.Client.Transfer is a new project rather than more of Client.Ssh. The two answer different questions — one is about reaching a host, the other about moving bytes and what to do when moving them stops halfway — and this is the only client project that deliberately touches the local filesystem. Three defects the tests found, none of which review would have. SftpPath.Name answered an empty string for the root. NavigateRemoteAsync wrapped itself in the busy guard, so navigating from inside another command did nothing at all and the remote pane simply stayed empty after connecting, with no failure anywhere to explain it. And opening an SFTP session per test made two handshakes per test — this client learns a host key by being refused — which pushed the SSH assembly past sshd's MaxStartups and failed a different few unrelated tests each run; the session is shared through the fixture now, with the reason written where the next person will hit it. 1004 tests green across 18 projects, 24 of them new: the SFTP subsystem against the OpenSSH container, the queue against a real temporary directory and a fake host, and three more layout measurements because a screen this window has never laid out is a screen never checked. Not verified: the screen has not been looked at running. The layout harness measures it at the window's minimum in three shapes, which is the class of defect that has shipped here before, but reaching it in the application needs the compose stack, the migrations, the API and a browser sign-in. What is still absent — the status bar's transfer count, dragging between the panes, transferring a directory, and sftp over a bastion — is in docs/design-import-gaps.md.	2026-07-31 11:07:29 +02:00
jaap-jan	94e11f5e38	update packages	2026-07-31 10:12:05 +02:00
jaap-jan	211eba0666	Keep host key trust in the vault, and make it withdrawable ... A fingerprint approved once is now approved on every machine and survives a restart, because host key trust is a vault item type rather than a dictionary that dies with the process. InMemoryKnownHostStore was what shipped, so the user was asked to verify a fingerprint on every single connection — which is the gap most likely to train somebody to click through the one warning that actually matters. A warning that appears when nothing is wrong teaches that nothing is ever wrong. The fourth item type, and like the third it cost no sync logic: a row, an EF configuration, a migration, a server kind; a secret, a codec, a merge, a cipher, a repository facade and a session property. One row in the client registry. The reconciler, the mirror, the repository, the outbox and the pull filter were not touched. SyncEntityType.KnownHostKey and AadResourceType.KnownHostKey were already reserved, so neither the contract nor docs/crypto.md changed. One item per (host, port, algorithm), because a server legitimately offers several host keys and which one gets negotiated is not ours to predict. Pinning per endpoint would make an algorithm change indistinguishable from an attack. The label is derived rather than stored, which is the one place this type departs from the other three. A user never names a pin — there is nothing to name it after but the three fields it already has — and a stored label is a second copy of data that can disagree with the first after a merge. Relabel returns the secret unchanged, and says why. The store answers the handshake without touching the disk. SshNetConnectionFactory calls FindAsync from inside SSH.NET's synchronous HostKeyReceived event, over .GetAwaiter().GetResult(), which cannot be avoided; doing SQLite I/O plus an AEAD open per lookup there would put the handshake behind the cache. So decryption happens in OpenAsync and RefreshAsync — on unlock and after each sync pass, exactly where the host and key lists already reload — and FindAsync is a dictionary read under a lock with no await inside it. That snapshot is where the one real bug in this change lived. Install originally merged the live pins over the freshly loaded snapshot, to protect a TrustAsync that had landed while the read was in flight. It would also have resurrected every pin the user had just forgotten, and stopped a withdrawal made on another machine from ever taking effect — the store would have healed the deletion back into existence on every refresh. Replacing wholesale and discarding the read instead is correct because writes are the rare case: every write bumps a generation counter, and a refresh whose stamp is stale throws itself away rather than winning. Nothing found this but reading the method again; it is the kind of mistake that passes every test written before it, because the test that catches it is the one the bug tells you to write. Forgetting is new, and persistence is what made it mandatory rather than convenient. A mismatch is a hard refusal with no way to continue — deliberately, and that stays — so pinning a key permanently is also a way to make a legitimately rebuilt server permanently unreachable. Before this change the pin died at exit and the problem solved itself; now it does not. ForgetAsync drops every algorithm for an endpoint, and it is reachable from the host editor rather than from the warning. Putting it on the mismatch banner would have made it two clicks from "this may be an attack" to "connect anyway", which is the affordance the hard refusal exists to deny. The banner already promised the key could be removed in the host's settings; that promise is now true and points at the button. Trust recorded on another machine becomes visible at the next sync pass, not immediately, and that is a decision rather than an oversight. The failure it produces is a first-contact prompt for a host a colleague approved a minute ago: answerable, and self-correcting on the next pass. The opposite trade — polling the vault on the handshake thread to close a one-minute window — buys nothing and costs the property above. The dangerous direction is not reachable at all: a pin recorded here enters the snapshot as part of recording it, so a refresh can never discard a local trust decision. The server learns nothing, and this is the item type where the temptation was real. A plaintext host column would let a known-hosts screen sort and page without decrypting anything, and it would hand the operator the map of every user's estate — assembled, as these things are, out of facts that are each individually harmless. A host row concedes an address only when relay is switched on and the database refuses to store one otherwise (ADR 0004); there is no equivalent excuse here. The table has no column to put one in, and the EF configuration says so where somebody adding it would be standing. Two things about the migration in this commit are worth knowing, because both came out of getting it wrong. It was hand-written first, including its .Designer.cs, and that version is not what is here. Verifying it turned up something that had been quietly assumed: Migration_AppliedCleanly_WithNoPendingModelChanges does not check the model snapshot. It asserts that migrations applied and that none are pending, which a wrong snapshot satisfies perfectly — the snapshot only matters as the diff base for the *next* migrations add, so an incorrect one passes the whole suite and corrupts the following migration instead. The real check is to generate a throwaway migration and confirm its Up and Down come out empty. They did, and the generated designer was byte-identical to the transcribed one across all 1255 lines, so the hand-written work was in fact correct. Then dotnet ef migrations remove --no-build deleted the wrong migration. With --no-build the tool reads the previously compiled assembly rather than the files on disk, and the probe had just changed which migration was last, so it removed AddKnownHostKeyItem and reverted the snapshot. That turned out to leave exactly the right diff base, so the migration here is EF's own output rather than a transcription — a better outcome than the one that was interrupted, arrived at by accident. Never pass --no-build to migrations remove. Mutation tested, all three sabotages detected: dropping the algorithm from KnownHostIdentity.For, merging instead of replacing in Install, and pointing KnownHostKeyCipher at PortForward — which is what a cast from the wire enum's 10 would silently produce. Each is caught both by an assertion about the mechanism and by a behavioural test that never mentions it; the resource-type sabotage is caught by the table from d10a38d and nothing else, which is what that table is for. The end-to-end slice now approves the real sshd's host key through the vault, pushes it, and reads it back on the second simulated machine — including a check that the server learned no address, and that the second machine answers null for an algorithm never offered. 845 tests green. Zero warnings, dotnet format clean. Three things are deliberately not fixed. A tombstone queued over a create that was never pushed is refused by the server as Invalid and parked; that is pre-existing for all four item types, and the fix belongs in VaultItemRepository.DeleteAsync rather than here. Deleting a host, or changing its address, orphans its pins — both are correct as trust decisions, since a pin describes an endpoint and not a bookmark, but nothing surfaces the leftovers. And there is no interface listing pins at all: trust is created at the connect prompt and withdrawn in the host editor. A known-hosts list is where the orphans would become visible, and it wants the vault column rework first, for the same reason the credential editor does.	2026-07-30 11:00:39 +02:00
jaap-jan	5fccd53824	Add the Avalonia app and the xterm renderer, and fix two real bugs ... The terminal works end to end. A new integration test drives a real sshd in a container through a real PTY, the real pump, the real loopback WebSocket with its token and origin checks, and a ClientWebSocket standing in for the page: the login banner arrives, typed input round-trips, and `stty size` reports the 100x30 the session asked for. The only untested link left is xterm drawing bytes it was handed. The WebView is de-risked on Windows, which was the plan's largest risk. Not by assertion: with the app running there is an established TCP connection from msedgewebview2 to the data plane port, so WebView2 launched, navigated to the loopback page, executed terminal.js, and completed the WebSocket handshake against the real token and origin checks. Linux remains unproven and the package's own release notes now corroborate the concern -- Linux uses a WPE backend, and it ships a NativeWebDialog described as useful where embedded WebViews may be unavailable. Two bugs found by building it, both of which would have shipped: - ShellStream.Write buffers and needs an explicit Flush. Without one a keystroke is accepted, reported as written, and never reaches the remote: the terminal displays output perfectly and simply stops responding to input. SSH.NET's own WriteLine flushes, which is why the earlier spike never hit it. Found by isolating the pump against real SSH and reading BytesRead=51 -- banner and prompt through, nothing after. - The Windows app manifest needs a supportedOS list, or Avalonia's native control host fails outright and the terminal never starts. Also fixed a genuinely flaky test I happened to catch: SyncCursorTests tampered with the *last* base64url character, whose low bits the decoder ignores when the input length is not a multiple of three -- so a tampered cursor sometimes decoded to identical bytes and verified. It failed roughly one run in thirty, depending on a random key. Now tampers the penultimate character, which is fully significant at every length; 40 consecutive runs are clean. xterm 6.0.0 plus the fit and webgl addons are vendored as UMD bundles rather than built with npm, so a clean clone needs only the .NET SDK. Provenance and licences are recorded next to them, along with the UMD global names terminal.js depends on -- a bundle that switched to ES modules would load without error and leave Terminal undefined. The renderer acknowledges output from term.write's completion callback, not on receipt. Acknowledging early would return flow-control credit for bytes the screen has not caught up with, which is the one thing the credit window exists to measure. TerminalWorkspace moved into DodoSSH.Client.Terminal: it has no Avalonia dependency, and having it there is what let the end-to-end test exist at all. 404 tests pass, zero warnings on a clean rebuild, format clean.	2026-07-28 22:30:42 +02:00
jaap-jan	eb354bcdd9	Add the SSH session layer and the terminal data plane ... The throughput harness the plan requires before any UI, plus the SSH plumbing under it. 94 new tests, no WebView involved. Credit-based flow control is what makes `yes` survivable. A terminal renders at 60 Hz at best while a remote produces output as fast as the network allows, and the difference has to accumulate somewhere or be refused. Credit is reserved *before* reading, never after: because the pump cannot read more than the renderer has room for, the coalescing buffer is bounded by the window rather than by how fast the remote can talk. When credit runs out the pump stops reading, SSH's own receive window closes, and the remote sshd blocks -- backpressure to the source with no custom protocol. Verified by falsification, not just by passing: with the credit gate removed three tests fail, including the throughput harness's bounded-memory assertion. Acknowledgements are clamped because they cross into JavaScript, where a buggy or hostile page could otherwise claim to have rendered a gigabyte and talk the host into an unbounded read. Host key trust is enforced by *failing* the connection rather than prompting inside the handshake. SSH.NET raises verification synchronously, so consulting the user there would block the handshake on a UI round trip and deadlock the first time the prompt needed the UI thread. Unknown host and changed key become distinct exceptions the caller resolves asynchronously. A mismatch has no retry path at all: a dialog offering to continue is how users are trained to click through the one warning that actually indicates interception. A legitimately rebuilt server is handled by removing the pin in settings, away from the moment of connecting. The data plane serves the renderer page from the same loopback listener as the socket, which makes Origin predictable -- always http://127.0.0.1:{port} -- where a WebView virtual-host mapping would give a different origin per backend and nothing to validate. The token is substituted at serve time, so it never touches disk and never appears in a URL. Being clear about what that buys: not protection from a process running as this user, which can read our memory anyway, but from a page in the user's browser attempting WebSocket connections to loopback ports, which is a real and routine thing. Two bugs the tests caught. The accept loop handled connections serially, so an upgraded WebSocket parked it inside the receive loop and every later request went unanswered -- the page's own script among them. The suite hung rather than failed, which is how I found it. And SHA-1 is unavoidable here: RFC 6455 mandates it for Sec-WebSocket-Accept, where it authenticates nothing. Suppressed narrowly with that reasoning; the alternative, HttpListener.AcceptWebSocketAsync, throws PlatformNotSupportedException off Windows.	2026-07-28 21:58:55 +02:00
jaap-jan	885fb17bdc	Clear the SSH gate: window-change reaches the remote, and licence as MIT ... Licence is MIT, set solution-wide rather than only on the packable project: DodoSSH.Contracts is published so clients can build against it, and a package with no licence expression is one a corporate policy scanner rejects outright. The SSH.NET spike is the M1 client gate and it passes. SSH.NET 2025.1.0 exposes ShellStream.ChangeWindowSize, but a method existing is not the remote observing it, so the tests read `stty size` back from a real sshd after resizing rather than asserting the call did not throw. Repeated resizes each take effect too, which matters because dragging a window edge produces a stream of them. The IChannelSession fallback is not needed. Also verified against a real sshd: password and public-key auth, that the host key arrives as a raw blob we can fingerprint ourselves rather than reading SSH.NET's MD5 property, and that refusing the key via CanTrust actually aborts the connection -- without which the TOFU dialog would be decoration. Kept as a permanent suite, not deleted after the spike. An upgrade that silently stopped sending the request would present as wrapped output only after a resize, which is easy to misattribute to the terminal emulator. Two bugs in the test itself, both worth naming because either would have been read as "resize does not work": - A PTY emits CRLF, and the anchored regex rejected the CR. The output visibly contained `24 80` while the match failed. - Each read can begin with output still buffered from the previous command, including its size line. Taking the first match would have reported the pre-resize size. platform-flags.md now records window-change as resolved rather than unverified -- a stale flag is worse than none -- plus the three real SSH.NET limits found on the way: ShellStream does not override ReadAsync so every idle session parks a pool thread, one connection cannot serve both SshClient and SftpClient, and agent forwarding needs an upstream change.	2026-07-28 16:52:09 +02:00