a763f4b1133b76ed1b97b7cca834cf4b50c96118
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 jaap-jan
|
a763f4b113 |
Merge pull request 'Stop the SDK's own trimmer version deciding whether CI can restore' (#11) from claude/illink-lock-drift into main
Reviewed-on: #11 |
||
|
jaap-jan
|
93e35a0095 |
Stop the SDK's own trimmer version deciding whether CI can restore
CI went red across the whole repository — main's run 125 and every open pull
request at once — on a restore that never reached a compiler:
error NU1004: The package reference Microsoft.NET.ILLink.Tasks version has
changed from [10.0.10, ) to [10.0.11, ). The packages lock file is
inconsistent with the project dependencies so restore can't be run in
locked mode.
Nothing in any of those commits touched a package. .NET had shipped SDK 10.0.400.
◆ THE VERSION IN THE LOCK FILES WAS NEVER THIS REPOSITORY'S TO DECIDE.
Microsoft.NET.ILLink.Tasks is referenced by nothing here. The SDK adds it to any
project setting IsTrimmable or IsAotCompatible — DodoSSH.Contracts and
DodoSSH.Crypto do, and the Android head gets it from trimming being on by
default — and it supplies the version itself, from the KnownILLinkPack item in
its own Microsoft.NETCoreSdk.BundledVersions.props. 10.0.302 says 10.0.10;
10.0.400 says 10.0.11.
packages.lock.json records that as a Direct reference with a requested range, so
what the committed file actually means is "whichever SDK last ran a restore".
global.json says rollForward: latestMinor, so setup-dotnet installs the newest
10.x SDK that exists on the morning it runs. The gate did its job — an unreviewed
dependency change is exactly what it is there to stop — but the change it caught
was not one anybody could have reviewed, and it will recur on every servicing
release.
Regenerating the lock files alone would have been the worse repair, and not only
because it holds until the next release. It cannot be done from this machine at
all: every SDK installed here tops out at 10.0.302, which writes 10.0.10 straight
back and re-breaks CI. The recorded version would flip according to who restored
last — the precise state locking exists to prevent.
So the version is pinned in Directory.Build.targets and the three lock files are
regenerated against the pin. It is an Update on the SDK's item rather than a
PackageVersion in Directory.Packages.props because the reference is implicit:
the SDK supplies a version, so central package management is never consulted. It
sits in a target because the conditioning is on %(TargetFramework) — all the
KnownILLinkPack items share one identity and only that metadata separates
net10.0's from net8.0's — and item batching in a condition is legal inside a
target and MSB4191 during evaluation.
Pinned forward to 10.0.11 rather than back to 10.0.10, which would have been a
one-line change with no lock file churn. Holding the trimmer a release behind the
framework it analyses to dodge an error is how a missed trim warning happens, and
taking the newer one makes the bump a reviewed diff, which is what the gate was
asking for.
Verified against the SDK that broke it rather than only the one here:
- sdk:10.0-alpine, 10.0.400, `dotnet restore DodoSSH.slnx --locked-mode` —
exit 0. That is ci.yml's line, on CI's SDK.
- the android workload on sdk:10.0-noble, 10.0.400, locked-mode restore of
DodoSSH.Client.Android — exit 0. That is scripts/ci-android.sh's line.
- locally on 10.0.302, the same locked-mode restore of the solution — exit 0.
One set of lock files satisfying both SDKs is the whole point of the pin, and the
third check is the one that demonstrates it.
Release build clean: 0 errors, and 0 IL-prefixed diagnostics from the newer
analyser on the two trimmable projects. 1,869 tests over 19 suites, none failing.
A caution for the next person, learned the hard way here: `--force-evaluate` on
Windows rewrites every lock file it touches with CRLF, and 23 of the 26 had no
content change at all. Only the three that really moved are in this commit.
|
||
|
jaap-jan
|
b80bf23341 |
Merge pull request 'Stop one tab's status banner from speaking for all the others' (#10) from claude/status-bar-tab-isolation-caa52b into main
Reviewed-on: #10 |
||
|
jaap-jan
|
8c58e5a558 |
Stop one tab's status banner from speaking for all the others
A shell that ended printed "The remote closed the session." into the status banner at the foot of the terminal. Switch to a tab whose shell was still very much alive and the sentence was still there, sitting under a live prompt and describing a terminal that was no longer on screen. There is one #status element for the whole page, because there is one page for every terminal — the panes are stacked in the same box and all but the active one are hidden — and SESSION_CLOSED wrote its reason straight into it. The other half of the same mistake ran the other way: SESSION_OPENED and SESSION_REMOVED both cleared the element outright, so opening or closing any tab wiped a message that belonged to a different one. Whichever tab spoke last owned the banner. The fix is to separate the two things that were being put in one place by who they are actually true of. A session's last words are a fact about one terminal and are now held on the session record, drawn only while that session's pane is the one showing; activate() re-renders, so the banner follows the tab and a dead tab still says what became of it when you come back to it. The socket's own state — "Connecting…", "Reconnecting the terminal view…" — stays page-wide, because there is a single socket behind every pane, and it wins when both have something to say: a page whose socket is down is not showing live output on any pane. A SESSION_CLOSED for a session this page has no pane for is now dropped rather than printed. There is nothing to attach it to, and putting it in the banner anyway is precisely the bug in miniature. Verified by driving the real handleFrame through a stub DOM under node, which is as close as this repo gets — there is no JS test harness and CI runs dotnet only, so nothing here is a standing test. Twelve checks over open, close, switch, reopen, remove and a socket drop pass against this file; the same script run against the previous one reproduces the report exactly, epitaph under a live tab included. Not seen in a running app: no C# changed, and the page is unreachable without one. |
||
|
jaap-jan
|
53ff15ba86 |
Keep drawing the terminal after Android takes the GPU context away
The phone's terminal was blank whenever it was connected. Not slow, not mis-sized, not disconnected: a live session accepting keystrokes, acknowledging output and drawing nothing at all. ◆ THE WEBGL ADDON DOES NOT RECOVER FROM A LOST CONTEXT AND DOES NOT FAIL LOUDLY. It stays loaded over a dead context and renders an empty rectangle, which is xterm's documented behaviour and the reason its guidance is to subscribe to onContextLoss and dispose. This page never did, and until there was a phone there was no reason to notice. Losing the context is ordinary on Android and nearly unheard of on Windows, which is what made this a one-head bug in shared code. Collapsing the renderer sets the native view to GONE — Avalonia's AndroidNativeControlHostImpl.HideWithSize, read out of the assembly rather than guessed at — and a WebView with no surface has no GL context. The shell collapses it every time a tab starts connecting, every time the connect sheet opens and every time the app is backgrounded. Worse, the ordering guarantees it for the first session on every launch: OpenSessionAsync sends SESSION_OPENED before the tab reports a session, so IsTerminalShowing is still false and the pane, the terminal and its GL context are all built inside a collapsed WebView. WebView2 hides a child HWND and keeps rendering throughout, which docs/platform-flags.md measured at length. The addon is not reloaded after a loss. A pane that lost the context once is on a surface that will do it again, and thrashing between renderers is worse than being slow — the DOM renderer is what the existing fallback comment already argues for, because a blank pane is not usable and a slow one is. The comment above MINIMUM_FITTABLE_PIXELS was wrong for this head and is corrected with it. It asserted that collapsing the WebView leaves this page's viewport alone, so no observer fires and the guard protects nothing — true of a hidden child HWND, false of a GONE view, which its parent's layout skips outright. On the phone the guard is the only thing standing between a lock, a connect sheet or a trip to the background and a remote pty reflowed to 2x1. Also on the way past: the renderer-timeout message told phone users to install the Microsoft Edge WebView2 runtime. That is the other blank-terminal failure mode's message, and naming a runtime that cannot exist on the device is worse than saying nothing at the one moment somebody is trying to work out what went wrong. It now names Android's own WebView on that head, as a runtime check for the reason MainWindowViewModel.GestureWait records beside its own. Not verified on a device — there is no handset or emulator here, and no test covers this page. The diagnosis is the decompiled hide path plus xterm's own requirement, not an observation. 523 tests over the shell and the terminal pass, and both heads build. |
||
|
jaap-jan
|
766fe6aebe |
Stop the test sshd penalising the suite for its own host-key refusals
The SSH suite has failed intermittently for months with SshConnectionException "The connection was closed by the remote host", within milliseconds, on whichever class happened to be running. Two previous attempts guessed at the cause and said so honestly; this one has a mechanism and a before/after. ◆ THE CAUSE IS PerSourcePenalties, WHICH THIS SUITE PROVOKES BY DESIGN. OpenSSH 9.8 added per-source penalties and 10.x enables them by default; the image runs 10.3 and its config never mentions the keyword, so the compiled-in default was what ran. A source address that repeatedly disconnects without attempting authentication gets penalised, and while the penalty holds every connection from it is answered with the clear-text line "Not allowed at this time" and then closed. That is exactly the traffic this suite generates. This client's first contact with an unknown host is a connection deliberately refused at the host key — a disconnect with no authentication attempt — so every helper that learns a host key by being turned away first, plus RefusingTheHostKey_AbortsTheConnection and AnUntrustedHost_IsRefusedExactlyAsAShellWouldBe, feeds the penalty counter. Enough of them close together and sshd stops talking to the test host for a while, then starts again. Measured on a fresh container, probing 200 times with connections of that shape: with the image default, the first refusal came back at probe 18 and 183 of the 200 were refused. With PerSourcePenalties no, none of 200 were. That is the before/after the earlier attempts could not produce. It also explains the shape of the failure, which never fitted a throttle. The class that failed lost EVERY connection it made rather than a random few — including the one test that expects a refusal, which passed throughout for the wrong reason — while the classes around it were untouched. That is a window in which the server refuses one source, not a probabilistic drop. Both earlier diagnoses are recorded in the fixture so they are not tried again. MaxStartups was blamed on the reasoning that xUnit runs test classes in parallel, so ten unauthenticated connections would be in flight at once; but every class touching this server shares one collection and xUnit parallelises collections, not classes, so they run one after another and never have more than a connection or two open. The reload window was blamed next, and a wait for the banner was written and removed as unproven — it was unproven because the banner answers perfectly right up until the penalty lands, so a check that stopped at the first "SSH-" ran entirely inside the good part. MaxStartups is kept, on the narrower argument that it is right regardless: a connection throttle is hardening a test server has no business reproducing. Removing it would be a second change riding along with this one. The readiness gate that replaces the reconfigure's silence is a guard rather than a wait. It requires 25 connections answered back to back, which is the specific provocation rather than a soak test: 25 is above the measured threshold of 18 on purpose, and it costs under a second when the setting is off. Ten was tried first and was worse than useless — it sits below the threshold, so it passed against a server that was still penalising. With the fix removed the gate now fails in a minute naming PerSourcePenalties and quoting the server's own "Not allowed at this time", instead of the suite failing later somewhere unrelated. The gate also closes a hole the container's own readiness cannot: a log line and netstat showing :2222 both pass on a container whose sshd has gone, because Docker publishes the port with a host-side proxy that accepts before it has anything to forward to. It is probed from the host rather than with docker exec for the same reason it matters — that is the path the tests take, and penalties are counted per source address. Rejected: patching sshd_config from /custom-cont-init.d to avoid the reload entirely. It looks like the right hook and is not — the container's log puts "sshd is listening on port 2222" before "[custom-init] Files found, executing", so a script there edits a file the running server has already read. It leaves a config that greps correctly and a server behaving as though it were never touched, which is the same trap as patching the wrong one of the image's two config files. Twenty-eight tests failed before that was noticed; the finding is in the fixture. Four consecutive full-solution runs clean, and the SSH suite green on every run since. 1,861 tests, none failing. |
||
|
jaap-jan
|
9f73893e14 |
Merge pull request 'Give the terminal back the width and the keyboard the session shell took' (#7) from claude/quick-access-terminal-fixes-565d4a into main
Reviewed-on: #7 |
||
|
jaap-jan
|
ccaf7a8e72 |
Give the terminal back the width and the keyboard the session shell took
Seven things reported from a day's use of v5b's session shell, and they are one commit because five of them are the same complaint from different angles: the window spends too much of itself on chrome describing the session, and the parts that are not chrome do not behave. ◆ THE HOST HEADER IS GONE, and that is a deliberate departure from the design. Terminal.dc.html and SFTP.dc.html both draw a 60-pixel row above the pane: the address on the left, a cross-surface button on the right. Both facts are worth having and the strip they sat in was not — the tab already names the host, and a full-width bar repeating it was the cheapest 60 pixels in the layout to give back. The address is now the first line of the sidebar and the button is stretched across the column under it, so nothing is lost and the pane is taller. Which word that button carries and which command it runs used to be handed in from the two usage sites in MainWindow.axaml, because the control was drawn twice. One sidebar cannot do that, so SessionCrossSurfaceLabel and OpenOtherSurfaceCommand resolve it in the shell — the same place SessionAddress already decides which surface's fact to read. The two directions underneath are untouched: SelectFilesHostAsync for a tab's host, OpenTerminalForFilesHostAsync for a fresh terminal at whatever SFTP has open. SessionHeader.axaml is deleted rather than left unused, and LayoutHarness stops subtracting its 60 pixels from every session screen's budget — the same treatment the retired window-wide tab strip got, and for the same reason: a constant for chrome nobody draws is a suite quietly measuring the wrong rectangle. ◆ AND THE SIDEBAR CLOSES, which the design has no state for at all. 300 pixels of an 1081-pixel minimum is a great deal to spend on a list that is often two rows long. The column now folds to a 34-pixel rail carrying the chevron that brings it back — a rail rather than nothing, because a panel that vanishes leaving no trace is one people report as lost rather than as closed. Both states live in the one control and swap on IsSessionSidebarOpen, so MainWindow's own "Auto" column takes whichever width is showing without knowing the state exists. Written through to ClientSettings.SessionSidebarOpen rather than held for the session. It is a decision about how much of the window a terminal gets, and one that had to be made again on every launch would not really be on offer. ---- THE FOUR SMALLER ONES ---- A SNIP LANDED IN A TERMINAL NOBODY COULD TYPE AT, and looked selected when it got there. Two causes with nothing in common. The click moved Win32 focus onto the sidebar row, and term.focus() in the page cannot take it back — only the host can, so the shell raises TerminalFocusRequested and the window answers with the same posted focus every other path here uses. The highlight was bash: xterm wraps a paste in bracketed-paste markers, readline marks what arrives inside them as an active region, and it stays in reverse video until the next keystroke. Right for a clipboard paste, wrong for a snippet picked off a sidebar. Single-line snips are typed rather than pasted now, which needs no markers; multi-line still pastes, because "runs three commands unasked" is the worse of the two failures and the markers are the whole of what prevents it. A BLACK BAR UNDER THE TERMINAL, on Windows. xterm.css paints its scrolling viewport #000 — its own comment explains why, and it is a macOS scrollbar concern. Everywhere else that black is covered by the rows, except along the bottom: the fit addon floors the row count, so the remainder below the last whole row is bare viewport, up to a line tall, against this page's #171a26. The light square at its right-hand end is where WebView2's classic scrollbar corner lands. The viewport is repainted in the page's own background, and the scrollbar with it — thin and in these colours rather than a grey Windows channel down the side of a near-black terminal, and kept rather than hidden, because a surface that scrolls with no sign that it does is worse than a quiet bar. THE PINS ROW DREW A TOFU BOX. U+E946 is not in the embedded Material Icons face at all — that file is the 2019 build and its cmap skips E944 and E946 — so the rail's Pins row and the hosts screen's own pin badge have both been drawing a missing-glyph rectangle since v5b picked the codepoint. push_pin in that vintage is U+F10D, verified against the file rather than against a codepoints table for a later release of the font. Every other icon codepoint in the repository was audited the same way; this was the only miss. THE KBD CHIP CUT THE CHORD IN HALF. 34 pixels is the design's width for a chip reading ⌘K, and this build substitutes CTRL K — six characters and a space, wider than 34 at 10.5 mono. MinWidth and padding instead, so the design's footprint survives for the day this face has a ⌘ to draw. ---- AND THE POPOVER UNDER THE USER CHIP ---- Reported as not matching the design, and it was not: Button.poprow set a corner radius and a padding and never touched the Background, so every row wore the Fluent theme's own #33FFFFFF button fill. Six raised pills stacked in a menu the design draws as six lines of text — and the hover rule underneath was already correct and simply invisible against a fill that never went away. Set on the ContentPresenter as well as on the Button, the same as Button.flat, because the theme binds its brush there and a Background set only on the control loses to it. The panel itself gets this window's own radius-12 card treatment through a FlyoutPresenter class rather than by widening the shared context-menu rule, and Vaults and Preferences stop being drawn one step dimmer than Settings and Logout, which read as two disabled entries in a menu of five live ones. ---- WHAT PROVES IT ---- Three tests in the layout suite, two of them checked against the defect they describe: the popover row's resting fill (fails with #33ffffff without the style), and the kbd chip against the natural width of its own text, measured on a detached copy because a TextBlock's DesiredSize is already clipped to what it was given and reports 34 inside a 34-pixel chip either way. SessionSidebarTests is new — the sidebar has never been laid out by a test, and it now holds a string of unbounded length beside a button that has to stay clickable. In the shell suite: the cross-surface row in both directions, the closed state surviving to disk, and the focus request being made when a snip lands and not made when it does not. |
||
|
jaap-jan
|
6fc1e3a7c5 |
Merge pull request 'Say how far a connection has got while it is still being made' (#6) from claude/connection-status-indicator-e52da7 into main
Reviewed-on: #6 |
||
|
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. |
||
|
jaap-jan
|
9755b5f6ae |
Merge pull request 'Stop the SSH suite's server refusing connections at random' (#4) from claude/ssh-fixture-hup-race into main
Reviewed-on: #4 |
||
|
jaap-jan
|
afc6a042f1 |
Merge pull request 'Let the host editor make the credential it is about to bind' (#5) from claude/host-credentials-saved-sets-1786d4 into main
Reviewed-on: #5 |
||
|
jaap-jan
|
e41eca01a8 |
Stop the SSH suite's server refusing connections at random
The suite fails intermittently with SshConnectionException "The connection was closed by the remote host", within tens of milliseconds, on whichever test happens to connect first. It has been seen in CI and reproduces locally. This raises sshd's MaxStartups in the fixture, which is the most likely cause and is worth doing regardless. sshd's compiled-in default is 10:30:100: past ten unauthenticated connections in flight it refuses new ones at random, thirty percent of the time, rising to always at a hundred. The image ships the line commented out, so that default was what ran. xUnit runs test classes in parallel and most of the classes here open a connection, so ten in flight is reachable during the opening seconds — and a refusal presents to the client exactly as observed, because a dropped connection and a server that never answered are indistinguishable from that end. ◆ IT IS A MITIGATION AND NOT A DEMONSTRATED CURE, AND THE COMMENT SAYS SO. The flake rate could not be measured. On the Windows development machine the identical unmodified suite ran 85/85 clean and, an hour later, failed 13 runs out of 15; a Linux container gave 30/30 clean and then failed on the first run of the next batch. Docker throughput on that host swings far enough to swamp the effect, so every before/after comparison taken there was noise — including two that were briefly believed. It is committed on the narrower argument that it is right either way. A connection throttle is hardening this suite has no interest in reproducing: it exists to test an SSH client, not to survive a rate limit, and a test server that drops connections at random is a bad test server whether or not it is the cause of this particular flake. The other candidate was the reload window — pkill returns when SIGHUP is delivered, not when sshd has finished closing its listeners and re-execing, so a connection immediately afterwards can be refused the same way. A wait that required three consecutive banner reads before returning was written and then removed: it could not be shown to change anything either, and a fixture carrying two unproven fixes for one symptom is worse than one, because the next person has to disprove both. Both candidates, and how to tell them apart with sshd's own log, are recorded in the fixture and in docs/platform-flags.md. |
||
|
jaap-jan
|
e96d01aab9 |
Let the host editor make the credential it is about to bind
The authentication picker has listed saved credentials since they existed, but making one meant leaving a half-typed host for the keychain screen and coming back to find it gone. On the phone it was worse than a detour: that head has no credential editor at all, so it could bind a host to a credential and never produce one. + NEW CREDENTIAL opens a card under the picker — name, optional username, password, notes — and ADD writes it and binds the host in one step. A button beside the picker rather than an entry inside it. Every row of that list is a binding a host can have, and "make a new one" is an action: as an entry it would sit in the box afterwards describing a state no host can be in, and cancelling the form would leave the picker showing it. It carries its own five fields rather than reusing the keychain editor's, and that is the load-bearing part. IsEditingCredential is what AVaultEditorIsInTheWay asks about, so sharing it would have made the whole Vault screen refuse to open an editor while this card sat open on the Hosts screen, with a status line naming a form the user cannot see on a screen they are not looking at — the exact failure that guard was split in two to end. A test pins it. It writes to the keychain immediately, unlike every other field in this editor, because a credential is a shared item with an id and a host can only name an id that exists. The consequence is honest rather than hidden and the hint says so: a credential added this way outlives a cancelled host edit. What was still being typed does not — every path that closes the host editor clears the form, and one of those fields is a password. The binding is written before the reload rather than after it. RefreshOpenEditors rebuilds this picker and then restores it from the editor's own selection, so setting it first is what survives the pass, and by the time it is read ReloadCredentialsAsync has put the matching entry in the list to land on. A name already taken is duplicated, not reused, and that is a deliberate parting from the new-tag box six lines further down which offers the existing tag instead. Two tags called "staging" are one intention spelled twice; two credentials called "root" are two different passwords, and quietly binding the host to whichever was there already would authenticate it as an account nobody chose. A duplicate label in the picker is the smaller problem. Into editingHostVaultId, so the credential lands wherever the host is being sealed and everybody who can read the host can read what it authenticates with. Stricter than the tag path — which files into the active vault and is recorded as a gap in docs/design-import-gaps.md — and it can be, because this picker lists credentials from every readable vault rather than one. Five flow tests cover the bind-through-reload path, the cancel semantics on both the saved credential and the abandoned one, the cross-screen guard, the duplicate name and the empty-password refusal. The layout test is separate and necessary: the card is collapsed until somebody presses the button, so a harness driven by the default state draws none of it, and TheHostDrawerFitsWithTheHostEditorOpen would have gone on passing over a card that blew the column. 1,854 tests, none failing. |
||
|
jaap-jan
|
7f77539ba6 |
Merge pull request 'Give the desktop a macOS head, signed from the first release' (#3) from claude/macos-build-release-2a8a0d into main
Reviewed-on: #3 |
||
|
jaap-jan
|
ca081af209 | Merge branch 'main' into claude/macos-build-release-2a8a0d | ||
|
jaap-jan
|
890a5f2246 |
Give the desktop a macOS head, signed from the first release
The same application, the same Velopack and the same two-phase person-run release as Windows, with four things forced to differ. Signing is a precondition rather than an improvement: Gatekeeper refuses an un-notarized download outright instead of warning about it, so there was never the "unsigned for now" that ADR 0013 decision 8 argues for on Windows, and release-macos.sh refuses to start without the identities. The packaging split is narrower than it first looked, and the old claim at the foot of ci.yml is why it was worth checking rather than assuming. vpk cross-compiles when told to: 'vpk [osx] bundle' builds a real .app on any platform, and CI now publishes osx-arm64 and bundles it on every main and tag build, which is what catches a restore graph with no macOS native asset. There is no '[osx] pack' off a Mac, and that part is correct — pack drives codesign, notarytool and stapler, which exist nowhere else. The dylib signing loop in the script looks redundant beside vpk's own pass and is not. vpk signs with 'codesign --deep', which is the shape Apple documents as wrong for nested code, and platform-flags has recorded a notarization rejection that names no file since before any of this existed. Signing each native binary inside-out first leaves that pass nothing to get wrong. MacDeviceKeyStore reaches ADR 0007's conclusion through different hardware: a P-256 key in the Secure Enclave under an access control requiring user presence, so the platform enforces the gate rather than this process — which is the whole point of that ADR's amendment. The enclave holds no other kind of key, hence ECIES where Windows uses RSA-OAEP, and the shape that falls out is better than the Windows one: sealing needs only the public half and is silent, so only unlock prompts. IsSupported probes rather than infers, because three ordinary Macs answer no — an Intel machine without a T2, one with no login password, and every unsigned development build, since enclave keys need a signing identity. Two decisions worth stating because they are reversible. arm64 only: a second channel is small work and nobody here has an Intel Mac to walk Phase 18 on, and an x64 package would be the only artefact in this repository reaching users unverified. And the pack id stays DodoSSH.Desktop even though vpk names the bundle after it, so /Applications holds DodoSSH.Desktop.app: decision 2's reasoning binds harder here, because a pack id of DodoSSH would put Velopack's install root on top of ClientPaths.DataDirectory and let an uninstall take the user's un-synced outbox with it. CFBundleDisplayName puts the product name back in front of a person. Measured rather than assumed, since none of it is obvious: the publish and the bundle were both run, LSMinimumSystemVersion is 12.0 because that is the minos in the apphost's own LC_BUILD_VERSION, and vpk copies a custom Info.plist verbatim with no substitution at all — which is why the plist is a template the script renders and not a committed file. What is not done is the half that needs the hardware. There is no macOS runner, so nothing past "it bundles" has ever run. Phase 18 is the whole of the verification, and the two checks most likely to fail are the terminal against WKWebView and the enclave interop, neither of which has executed once. |
||
|
jaap-jan
|
8c67fce32c |
Centre a phone row's caption in the row it is given
Button.row sets the height a thumb needs and left the caption's placement to Avalonia's Stretch default, so the content presenter stretched the caption to the whole row and a TextBlock draws its line at the top of what it is given — the same omission the desktop head's ghost/accent/danger rule had. Most of the thirty-three rows never showed it, which is what made the four that did look like four unrelated mistakes rather than one rule: a row whose content is a StackPanel or a Grid of already-centred children is centred whatever this property says. The four that are a bare TextBlock are FilesScreen's breadcrumb crumb, its up-one-directory chip and its pinned-path chip, and TerminalScreen's CLOSE THIS TAB — 36 or 44 tall with no vertical padding, so measured at those numbers the caption sat flush against the top edge with 21 to 33 pixels of nothing under it, eleven to seventeen pixels off centre in a control barely twice that tall. Nothing is excluded here, unlike the desktop's own sweep: no row's content depends on being stretched — there is no full-height strip inside any of the thirty-three, the thing that keeps flat and cat out of the equivalent rule over there — and the Grids that stop filling hold only children that already centre themselves, so they land where they always did. The other two phone classes that do not set it are both fine and neither should get it. RadioButton.chip declares its own ControlTemplate whose presenter reads VerticalAlignment="Center" outright, so it centres regardless and the property would not be read; Button.scrim is the full-screen dimmer behind a sheet and has no caption at all. Not covered by a test, and it cannot be from here: there is no Android layout suite, the desktop harness cannot instantiate net10.0-android views, and AvaloniaRuntimeXamlLoader — which would let it load Phone.axaml on its own — lives in a package this repo does not reference. What is verified is that the head builds, so the Avalonia XAML compiler has accepted the setter, and that the desktop's own 147 layout tests are unmoved. |
||
|
jaap-jan
|
0ffd259ccd |
Give the rest of the button shapes their content alignment too
The sweep the ghost/accent/danger fix implied: navuser, poprow, panechip, chiptoggle and choice each set VerticalContentAlignment now, because each set everything else about how its content sits and left that one to Avalonia's Stretch default. None of them was misbehaving. Every one is content-sized everywhere it is used today, so Stretch and Center agreed and this moves nothing — 113 buttons across 29 screens and cards measured byte-identical before and after, the strips that have no height of their own included. What it buys is that the day one of them is given a height, it is already right rather than quietly drawing its label in the top third. flat and cat are deliberately NOT swept in, and the reasoning that would sweep them is exactly the trap. flat carries the titlebar's search pill, a Border.searchpill with no height of its own that is meant to fill all 35 pixels of its button — the usage states HorizontalContentAlignment="Stretch" and takes the vertical default to match. cat carries the keychain rail's accent strip, a Border.rowmark whose style sets Width="2" and no height at all, "at full row height" by its own remark. Centring either from the style shrinks a pill and a strip that are correct today. AStretchingShapeStillFillsItsButton pins both, and fails when flat is centred. ButtonCaptionTests covers the five new shapes on the existing rule. Its stretch-fill assertion reads the content slot off the presenter rather than recomputing it from the button's Padding: the shapes differ in whether their presenter also draws a border, and a hand-rolled sum was two pixels out on Button.cat for that reason. |
||
|
jaap-jan
|
9bc9069425 |
Post the terminal's focus return past the dispatch that steals it
The first fix handed Android's focus back from inside the keys' Click handlers — which fire inside the UP event's dispatch, and Avalonia's own view requests focus for itself after every handled touch dispatch returns (AvaloniaView.DispatchTouchEvent, decompiled from 12.1.1). So the platform's request ran after ours and undid it microseconds later, which is exactly what the phone showed: the terminal still lost focus. The return is now posted onto the main looper, landing one message after the dispatch that stole, and it is wired at the row for both halves of a press — DOWN steals too, and Click only exists for UP, so a keyboard detached at DOWN would otherwise stay detached for the whole length of the press. Check 11.10a now also says what a tolerable blink looks like against a failure that stays. |
||
|
jaap-jan
|
e936ab4646 |
Announce a session's end when it is actually over, and for closes too
The phone's notification kept saying '1 shell connected' after the shell was gone, and both close routes were at fault. A shell exiting on its own raised SessionEnded from inside its run's finally block — where the run task is by definition not yet complete, so the LiveSessionCount the keep-alive reads still counted the dead shell, and nothing fired later to correct it. A tab closed by hand announced nothing at all, by a recorded decision that assumed every subscriber was the closer; the keep-alive is not, and a close it never heard about left the notification claiming a shell over nothing. The end is now announced from a continuation after the run completes, and CloseSessionAsync announces after its own drain — every subscriber was already a reconcile-to-reality handler, so the echo the old remark feared costs nothing. Shutdown stays silent: it is dismantling the subscribers along with the sessions. |
||
|
jaap-jan
|
506d2803a2 |
Hand Android's own focus back to the terminal after an accessory key
Focusable=false was only ever half the fix, and its remark now says so: Avalonia's focus stays on the NativeWebView, but the touch that presses a key still hands Android's native focus to Avalonia's input view — the platform moves it before Avalonia decides anything. The WebView's input connection dies with it, the keyboard swaps to its no-input layout, and the inset churn parks it over the very row that was tapped. Each key now returns that focus once its byte is on the wire, through a sibling of SoftKeyboard that walks the decor view to the one WebView this application has. Free when nothing moved. Check 11.10a is the phone-in-hand proof. |
||
|
jaap-jan
|
cc8bf37321 |
Merge branch 'claude/terminal-reattach'
Brings the Android keep-alive corrections and the terminal renderer reattach: the foreground service now actually comes up for shells and an idle Files session, survives refreshes from the background, and the terminal's data plane lets a reloaded WebView page take its socket back over instead of freezing every session behind a dead one. |
||
|
jaap-jan
|
3f5979d639 |
Record the renderer-reattach correction and its phone checks
The port notes carry the third correction of this round: the data plane assumed a renderer that attaches once and lives forever, which no foreground service can make true of Android's separate WebView renderer process. Phase 11 gains the two checks a phone can run — close and reopen a connection, and a backgrounded shell surviving its renderer being killed, banner and all. |
||
|
jaap-jan
|
aaff81272a |
Teach the page and the shell to put a reattached view back together
The page's socket now retries itself forever with backoff — a dropped socket is an ordinary event on a phone, not the end of the terminal's life — and createSession is idempotent, so a replay landing on a pane that survived changes nothing. A replay creating a pane that did not survive writes one dim line saying the earlier output stayed on the host, because that is the truth about a reloaded page's scrollback. The shell answers RendererReattached with the two things only it owns: the font size, and which tab is active. |
||
|
jaap-jan
|
4d1f07f253 |
Replay the live sessions to a renderer that just attached
Each live session gets its credit window reset — the unacknowledged bytes died with the old page, and their acknowledgement is never coming — and its SessionOpened frame again, flagged as a replay so the page can tell a reattach from a genuinely new session. A session whose shell already ended gets nothing: its scrollback lived only in the page that is gone, and a frame implying otherwise would lie. RendererReattached is the seam for what the workspace has no business owning: the font size and the selected tab live in the shell, which re-pushes them from its own subscription. |
||
|
jaap-jan
|
095774c498 |
Take a returning renderer's socket over instead of refusing it
One attach per process was WebView2's truth, not Android's: the phone kills the WebView's renderer independently of the app process, the page reloads, and its fresh socket was answered 409 by a guard that never reset — with no way back short of restarting the app. Only our own page knows the token, so a second valid upgrade is that page returning; it now displaces the old socket, which may never notice it is dead on its own, since a killed renderer sends no FIN. A send into the dead socket also no longer escapes as a fault. It used to unwind the pump's flush loop, after which nothing drained the credit window and the still-live shell froze behind it for good — including the BCL quirk where such a send surfaces as an OperationCanceledException nobody's token asked for. |
||
|
jaap-jan
|
3977f68870 |
Record the keep-alive corrections in the port notes and the manual checks
The port doc's backgrounding decision now carries the four corrections rather than describing a wiring that was not true, and Phase 14 gains the checks a phone can actually run: a backgrounded shell surviving, an idle Files connection surviving, the permission ask arriving at the first thing worth showing, and a refusal costing the notification and nothing else. |
||
|
jaap-jan
|
48ea5e22d5 |
Actually keep the phone's sessions alive when the app is backgrounded
The foreground service existed, and four defects in its wiring meant it mostly did not run. A shell opening was never announced to it — only the ending was — so the service never came up for a shell at all. An idle connected Files session counted as nothing. Every refresh restarted the service, which Android 12+ answers with a crash the moment the app is backgrounded — a transfer finishing in the pocket took the remaining connections with it. And POST_NOTIFICATIONS was declared but never requested, so on Android 13+ the receipt was silently invisible. Updates while backgrounded now go through the notification manager; a foregrounded refresh still prefers a real start, so a stop still in flight cannot leave an orphan receipt over an unprotected process. |
||
|
jaap-jan
|
810bc48d3f |
Tell the keep-alive wire when the Files session opens and closes
HasLiveFileSession answers the phone's foreground-service question — is there a connection here that dying with the process would sever — and a bucket answers no, because HTTP holds nothing open. ActivityChanged now also fires at the end of MarkHostConnected and CloseSessionAsync, where both facts it reads are finally true together. Also makes the bucket pins test actually open a bucket: it never set Remote, so CONNECT dialled the auto-selected host, and its assertions passed only because that host had no pins either. |
||
|
jaap-jan
|
671611a9a0 | Merge branch 'claude/phone-pins' | ||
|
jaap-jan
|
21cf77f64a |
Centre a button caption in the button, not just the button in its parent
App.axaml's Button.ghost, Button.accent, Button.danger rule set VerticalAlignment and never VerticalContentAlignment. The first places the button in its parent; the second places the caption in the button, and its default is Stretch — so on any of these given a fixed Height the content presenter stretched the caption TextBlock to the whole content box, and a TextBlock draws its line at the top of whatever it is given. Measured on the hosts toolbar, whose three buttons are 40 pixels: nine above the ink and twenty below it. Every box was the height it declared, which is why this read as one of them being the wrong height — nothing was mis-sized, the labels sat in the top third. Center rather than a hand-tuned Padding, because the gap is the difference between the line box and the content box and moves with the font size: these carry 11.5 by default and the primary action overrides it to 13.5. It is the three shapes that were missed rather than a new idiom — navseg, sesstab, headerghost, sidebarrow, fieldrow and paneicon all state it already, as does every one of the phone head's own button classes. 134 buttons carry these three classes; the ones that show it are those with an explicit Height, which is both toolbars, the drawer's Save/Cancel pair, and the import screen. A button sized to its own caption was already right and is untouched. HorizontalContentAlignment is deliberately left alone: it is Stretch too and invisible on a self-sized button, and the flyout rows that are stretched wide ask for Left themselves. ButtonCaptionTests measures a bare Button, since Application.Styles is global and a screen-level test would pin one toolbar and leave the rest to the same defect. It measures the laid-out line rather than the TextBlock's arranged bounds, and that distinction is the test: under Stretch those bounds fill the content box and so are symmetrical whether or not the ink in them is. The first draft asserted on them and passed against the defect; the calibration test caught it, and against the old markup all three shapes now fail naming their own gap. |
||
|
jaap-jan
|
dbf6ce1bcf |
Give the phone its pins: an editor section and chips on Files
The data was never the gap — HostSecret.PinnedPaths syncs and merges on both heads, and the desktop's drawer has staged it since v5 — the phone just had nowhere to add, remove or use a pin. Now it has both halves. The host editor page gains a QUICK ACCESS section over the same shared staging the drawer binds (EditorPinnedPaths, AddEditorPin, RemoveEditorPin), with the remove target at this head's 44dp touch floor rather than the desktop's 22-pixel close box, and no folder glyph because this head embeds no icon font for one. The page also gains a Status line of its own: the add command's five refusals speak through Status, and this page covers the screen that normally draws it — a refusal nothing shows is no refusal at all. The Files screen draws the connected host's pins as chips between the breadcrumb and the listing, each running GoRemoteCommand exactly as a crumb does. They are captured at connect, like ConnectedTo and the session facts before them; a bucket gets none, having no HostSecret to pin anything on. Covered headlessly in ShellFlowTests — connect populates, disconnect clears, a bucket stays empty — and by manual checks 8.18 and 8.19, whose phase preamble also stops claiming thirteen checks when it lists twenty-one. |
||
|
jaap-jan
|
242280ce6b |
Name a root chip after the root, not with its whole path
The chip derivation was TrimEnd(separator), which is a name only for the Windows drives it was written against: on Unix it made the / chip an empty pill and the home chip the entire home path, drawn at full width in a header column nothing bounds. A home directory deep enough — CI's per-job HOME is forty-six characters — had that one chip walk the header's own buttons out of the window at the session shell's 472-pixel budget, which is the half of the runner's red suite the star-column fix before this one did not reach. A chip says C:, /, ~, or a mount's last segment now; the full path stays on its command parameter, where length costs nothing. RootChipNameTests pins the derivation with fixed strings, so it no longer takes a machine with a deep profile path to ask the question. |
||
|
jaap-jan
|
de0b5f12ae |
Let the pane headers' paths actually trim
TextTrimming only acts when measure hands the block a finite width, and a horizontal StackPanel never does — it measures every child at infinity and an Auto grid column passes the full answer on. So both SFTP pane headers grew with their path, and a directory deep enough pushed the header's own icon buttons past the window's edge at the session shell's 472-pixel budget. The layout suite has said so on every CI run since v5b landed, and nowhere else: the runner's per-job HOME is a 46-character path, which is what the local pane opens on, and every developer machine's short profile path left the same test green. The path sits alone in the star column now — bounded width, working ellipsis — and the narrowest-budget test pins both panes to sixty-character paths so the question is asked on every machine alike; against the old markup that test fails on Windows too. |
||
|
jaap-jan
|
009b35e069 |
Cover the mixed-keychain regroup refusal headlessly
The two-keychain branch of VaultViewModel.RegroupChosenHosts had no test: 7.6a's manual walk was the only thing asserting that a mixed set gets the sentence instead of the picker. A ShellFlowTests case now ticks a host in each of two vaults, reads the refusal off the status line, and shows the same command opening the picker once the set is one keychain's again. Check 7.6a cites the test and keeps only the popup wiring for the eye. |
||
|
jaap-jan
|
d32f5609e3 |
Rewrite checks 7.6/7.6a for the picker that replaced the drag
The drag onto a group card went with v5's flat sections; filing a set is the chosen-hosts menu's "Change group..." picker on both heads now. The two checks walk that route instead and say honestly what ShellFlowTests and ScreenLayoutTests already cover, what only a real popup can show, and that nothing automated raises the mixed-keychain refusal. The numbering preamble's example swaps to citations that still exist. |
||
|
jaap-jan
|
9d5ff9f23a |
Draw what authenticated, and over what, on the session status bar
The v5b design's own row: the negotiated cipher, then the host key's algorithm and the name of the key or credential that authenticated, as one mono run beside CONNECTED — on both surfaces, off MainWindowViewModel's surface-aware SessionCipher and SessionIdentityText, the same shape SessionAddress set. The identity's name comes out of TryBuildAuthentication, the one resolution point that always had it in scope and always threw it away; it rides HostAuthentication to the tab and to the SFTP connect alike. Three deviations, recorded in the gaps doc: the algorithm prints as negotiated rather than shortened, the run is plain text because no pin-details modal exists for an open session, and a typed password shows the algorithm alone — there is no item behind the dot. A dead terminal tab keeps its facts for the scrollback still on screen; an SFTP disconnect, with no scrollback, clears them. |
||
|
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. |
||
|
jaap-jan
|
8915650a0d | Record the phone catching up in the design-import log | ||
|
jaap-jan
|
b931a06998 | Repaint the phone's chrome, radii and accent to the v5 vocabulary | ||
|
jaap-jan
|
ca48e18b57 | Give the phone the desktop's face: Montserrat by default | ||
|
jaap-jan
|
c59b517fdf | Record v5c in the design-import log, and true up the manual checks | ||
|
jaap-jan
|
bb2f973687 | Redraw the host keys screen with its pins' own facts beside it | ||
|
jaap-jan
|
c8507b44fe | Give the application a settings area built from what really exists | ||
|
jaap-jan
|
422d5ca10e | Record v5b in the design-import log, and true up the manual checks | ||
|
jaap-jan
|
d91729c0b8 | Restyle the keychain, the snips and the logs to their v5b shapes | ||
|
jaap-jan
|
43c939b697 | Give the window its v5b chrome and each session surface its own shell | ||
|
jaap-jan
|
1b76c51fbb | Name v5b's deep chrome, its track and its magenta in the palette | ||
|
jaap-jan
|
f3c0b9ca1b | Merge branch 'claude/friendly-elgamal-e085e5' into claude/v5-design-fidelity | ||
|
jaap-jan
|
7ca74a1e35 |
Retint the scrims to the v5 canvas, quick connect at the spec's 60%
Five scrim hardcodes still dimmed through the old canvas #0E1220; they now sit on #05050A. Each keeps its alpha except QuickConnect's backdrop, which the v5 spec pins at rgba(5,5,10,0.6) — its essay drops from 80% to 60% of Canvas to match. |
||
|
jaap-jan
|
d7f0bea258 | Repaint the launcher mark and the window icon in v5's own ink | ||
|
jaap-jan
|
7d64027972 | Record v5 in the design-import log, and let the working notes go | ||
|
jaap-jan
|
281e828e25 | Sweep out the group-card navigation nothing reaches any more | ||
|
jaap-jan
|
dca2e888d6 | Redraw quick connect in v5's shape, auth word and all | ||
|
jaap-jan
|
2ba7c14e35 | Restyle the drawer, pin folders on a host, and say when it was last connected | ||
|
jaap-jan
|
c3ef4bd8b4 | Flatten the hosts screen into one board of sections | ||
|
jaap-jan
|
369109dd4e | Write the disabled accent glow as 'none', which this Avalonia can parse | ||
|
jaap-jan
|
06f9dcfc27 | Snapshot the v5 hosts screen mid-restructure, with handoff notes to resume it | ||
|
jaap-jan
|
bea0279937 | Repaint both heads in the v5 palette and embed its three fonts | ||
|
jaap-jan
|
49645db680 | Let a host carry pinned folders, merged path by path | ||
|
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. |
||
|
jaap-jan
|
575a9a9f5e |
Stop the relay checkbox promising a connection this client cannot make
Ticking "Connect through the server relay" moved the host's address and port out of the encrypted payload into plaintext columns on the server — the single deliberate privacy concession in the design, per ADR 0004 — and then the client dialled the address directly, exactly as it does with the box clear. VaultViewModel builds SshConnectionRequest(hostname, port, username, credential) and nothing on this side reads RelayEnabled at all. The connection failed the way it always had, for a machine the laptop could not reach, with nothing saying the box had done nothing. The server half is built and shipped: tickets, the WebSocket, the deny list, the CHECK constraint that enforces a non-null address for a relay-enabled host. What does not exist is the client's path to it, so this is an unfinished feature rather than a broken one — but the control in front of it was collecting the cost of the finished version. Both heads now say so, in the label and in the first sentence of the paragraph under it. Not disabled, and that is the one decision here worth stating: a host somebody has already ticked has to be able to lose the flag, and a control greyed out with the concession switched on would trap it there. Tickable and honest beats untickable and stuck. This is step 0 of docs/reaching-a-host-you-cannot-dial.md, and the only step of it that should ship alone — the sentence is written to be deleted when the bridge lands. VERIFIED. Build clean, 112 layout tests. The drawer's paragraph is longer than it was and the host editor is measured with the drawer open at the window's minimum, so the wrap is held inside the column rather than assumed to fit. |
||
|
jaap-jan
|
6185d74800 |
Write down the two things a user is promised and does not get
Two plans, both for the same class of defect: a control or a code that a user is told to rely on, backed by storage and by nothing else. Neither is started; what follows is the reasoning, so that starting is not where it gets thought about. ── UNLOCKING WITHOUT THE PASSPHRASE ───────────────────────────────────────────────────────────────────── Every account is issued a recovery code at enrollment. The client generates it, wraps the identity bundle under KEK_rc, the server stores that wrap as UserKeyWrapKind.Recovery, and both heads work to make sure the user writes it down — the phone raises FLAG_SECURE for that screen alone and will not let anybody past it. Nothing can use it. SessionOpener has UnlockAsync and UnlockWithDeviceAsync, and there is no third. Walk the failure through: forget the passphrase, and the bundle cannot be unwrapped, so no vault key opens and every item is unreadable. Signing out and back in returns the same passphrase wrap. The device key would be the other door, and sign-out withdraws it — which is the advice the unlock screen gives for exactly this situation. The loss is total and permanent, and the thing built to prevent it is inert. The docs already disagree with each other about this, which is how it surfaced. manual-checks §10.2 calls the code "the only thing standing between a forgotten passphrase and an unrecoverable vault"; android-port says losing it *along with* the passphrase is what makes a vault unrecoverable; README says signing out is the only answer and nothing can recover one. The third is the true one today. More than half the work is already done and one piece of it was done on purpose: LocalCacheKey derives from the identity bundle rather than from MK — crypto.md §3.2, changed 2026-07-30 — specifically so an unlock that never computes MK can still read the cache it wrote. What is missing is an endpoint to serve the wrap, an unlock path, and a way to set a new passphrase afterwards, without which the account unlocks with a one-time code forever. That last step is the same re-wrap a change-passphrase feature needs, so it delivers both. Two traps are recorded because both would produce a code that verifies nowhere. The derivation uses the displayed string *including its dashes*, so the unlock must canonicalise to the printed form rather than strip it; and the recovery wrap uses a different Argon2 profile to the passphrase one (64 MiB against 256), so it must derive from the parameters served with the wrap rather than from a profile constant. ── REACHING A HOST YOU CANNOT DIAL ────────────────────────────────────────────────────────────────────── This started as "delete the dead jump-host field" and inverted twice. HostSecret.JumpHostIds is stored, validated, encoded and three-way merged, and nothing reads it or writes it — the ssh_config importer looks like the writer and is not; it records ProxyJump as an option and a note saying DodoSSH cannot honour it. The first draft recommended deleting it. That was wrong twice over. ADR 0004's last consequence had already designed the implementation — a loopback TCP bridge for the relay, and "the same bridge provides ProxyJump via a SOCKS5 dynamic forward", one mechanism and two features — which the pinned SSH.NET 2025.1.0 supports through ForwardedPortDynamic and ProxyTypes.Socks5, checked in Renci.SshNet.xml rather than remembered. And the stored shape is right: an ordered list of host ids is what a chain is, the merge arm is correct, and the missing schema version is a line to add. ◆ Looking properly found the same shape one field over, where it costs something. RelayEnabled is also stored, merged and never read by the connect path — but it is user-settable, and both heads draw a checkbox promising it. Ticking it moves the host's address and port out of the encrypted payload into plaintext columns, which ADR 0004 calls the single deliberate concession in the design, and then the client dials directly anyway. The privacy is spent and the feature is not delivered. That is a defect rather than a gap, and it is step 0. The comparison the plan turns on: the relay reaches what the *deployment* can reach and the jump host reaches what a *machine in the keychain* can reach, so they are not substitutes. On a self-hosted box outside the target's network the relay reaches nothing the laptop could not. And the privacy ordering is the opposite way round from the ADR's framing — the relay costs a plaintext address, the jump host costs nothing, because the operator is not in it. Both documents carry a section on what their own earlier reasoning got wrong, which for the second one is the load-bearing part: "nothing reads this field" was read as evidence of a mistake when it was evidence of an unfinished feature — and the same sentence one field over would have found the checkbox that is lying. |
||
|
jaap-jan
|
88809f0d66 |
Stop the docs claiming absences that have since been built
An audit of README.md, the seven docs and the fourteen ADRs against the code, looking for what is described as absent or planned. Most of it held. What did not is here, and it clusters: every stale claim but one is downstream of the settings file arriving without this document noticing. design-import-gaps said the client has no preferences store and writes exactly two files. It writes three — ClientSettings is in settings.json beside the cache — and two preferences are saved through it. From that one error followed four more: the terminal font size row said "fixed at the renderer's 13px" when it has been 8 to 32 from a screen and three chords for some time; the transfer-resume row and the per-host last directory row both blamed a store that now exists, when what they actually want is a table and a scalar file is the wrong shape for one; and the Preferences table asserted no preference could be saved at all. It also said TerminalServerOpcode has four values and none carries an option. It has eight, and one of them is FontSize — which is the interesting part rather than a counting error, because that opcode is the proof that the frame these rows say is missing can be built. The rows now say what each one would actually take, which for three of the four is a setting, an opcode and a control, and for the Backspace row is a reason: which byte backspace sends is a fact about the remote's stty, so a client-side switch fixes a mismatch by hiding it. THE SAME TWO ERRORS WERE SHIPPED IN THE INTERFACE. The preferences screen carries a NOT BUILT YET list, so that what the screen does not do is as legible as what it does — and it said terminal size was hard-coded a hundred lines below a working size control, and said there is one release channel a month after the nightly shipped. A list of absences is only worth having if it is true, and a screen contradicting itself in the same scroll is worse than no list. Both lines are corrected rather than removed: the first now says which three of the four are genuinely hard-coded, and the second says what is actually missing, which is a way to change channel from inside the application rather than by installing the other build. docs/adding-hosts-on-the-phone.md is deleted. It was a work plan whose own header says "Status: built. All six steps." — nothing links to it, and the decisions it records are in the code it produced, including the one it is proudest of: HostSecret.AsksForPassword carries its own remark on why naming neither binding had to stop meaning "ask me". What was left was step ordering and per-test instructions for work that shipped. Git keeps it. crypto.md is deliberately untouched. It is normative and frozen, and its claims are about the DSH1 format rather than about this build — including the one that reads oddly next to the code, that a passphrase is one of four ways to open a vault. Under the spec it is. What is missing is a statement about what this build can open, and that belongs beside the spec rather than inside it; see docs/unlocking-without-the-passphrase.md. VERIFIED. Build clean, 112 layout tests, 354 app tests. The preferences screen is measured by the layout suite, so the longer copy is held inside the window at the minimum size rather than assumed to fit. |
||
|
jaap-jan
|
d8cf16fb46 | Merge branch 'claude/windows-multiselect-support-37541c' | ||
|
jaap-jan
|
507cd9ff88 |
Choose more than one host card on the desktop, the way the phone already can
The chosen-hosts set has been in VaultViewModel since the phone's connect card became a contextual action bar: a set of entity ids, a tick on the row, and seven things that can be done to it. Only one head could fill it. The desktop's grid answered a press with one selection — the card the drawer, CONNECT and the context menu are about — so filing eleven imported machines under a heading was eleven drags, and clearing out a vault was eleven rounds of the deletion question. So the pointer gets three ways into the same set. Ctrl-clicks a card to tick it, Shift-clicks to tick the run between the anchor and the card, and drags a band out over the space between and below the cards to tick everything it touches. Esc, CLEAR, a plain click on a card and a click on the empty space each drop it, and Ctrl+A takes every card being drawn — VisibleHosts, so with something in the find box that is the ones on screen and not the ones it is hiding, which is the version of that shortcut whose result can be checked before Delete is pressed. TWO SELECTIONS ON ONE SCREEN, AND KEEPING THEM FROM DISAGREEING IS MOST OF THE CHANGE. Ctrl and Shift are answered on the tunnel and marked handled, so the ListBox never moves its own mark onto the card: a Ctrl-click that also selected would light the card it had just unticked and open the drawer on a machine somebody is removing from a set. A plain press drops the set unless it lands on a ticked card, and that case is deferred to the release, because the press may be the start of a drag of all of it. After any ordinary click exactly one card is in play, which is what makes every command on the screen unambiguous again. The context menu is where the seven live, and it is one markup with two halves gated on IsChoosingHosts. Connect, Browse files and Edit… are drawn only for a single ticked host, as the phone's sheet collapses them and for the same reason; the other four read better for a count. A right click on a card outside the set drops the set first, so a Delete… about the card under the pointer can never be offered while six sit ticked behind the menu — the same rule OnContextRequested has always enforced for the selection, reached from the other direction. No bar of buttons: the phone raises one because it has no other way to hold seven entries, and a strip repeating a menu that already exists would be a second home for the wording that matters most. What the desktop gains instead is a count beside the HOSTS heading, CLEAR, and a sentence saying where the actions are. A drag that starts on a ticked card carries every ticked card. The payload is a list rather than a row now, and a drop of more than one goes through FileChosenHostsUnder, which makes the refusals once — an open editor, and a group belonging to one keychain — and reports a count instead of forty status lines. Moving whichever card the pointer happened to be holding and leaving the other five where they are is a gesture that quietly does a fraction of what it looks like it does, and the five left behind look filed. The three panels the set's actions raise had never been drawn in a window: the vault picker with its key question, the group picker, and the deletion question. All three sit above the grid rather than over it, which is the arrangement the GROUPS section and the phone's list already use and for the reason written there — the ticked cards are the information the question exists to give, so the grid shortens instead. A DEFECT FOUND BEHIND IT, AND IT WAS ALREADY LIVE ON THE PHONE. The deletion question names a count and the run that answers it reads the set again, and nothing kept the two the same set: the panel is deliberately above a live list, so one more tick between "Delete these 6 hosts?" and pressing DELETE deleted seven, with the seventh named in nothing the user had read. It needed a deliberate act on a phone and a second's work with a band, which is what turned it up. VaultViewModel now remembers which hosts the question was asked about and drops the question when the set stops being them — the question rather than the set, because what somebody has just chosen is what they meant. It also covers the case nobody performs: a colleague's deletion arriving mid-question and shrinking the set under it. VERIFIED. 354 tests in App.Tests and 111 in App.Layout.Tests, build clean, no new warnings. Six gesture tests drive real pointer and key input through the headless window — the modifier click and what it must not do to the selection, the run and its re-measurement from the anchor, the band and the click that drops the set, Ctrl+A under a filter, and the menu's two halves — plus a DragOver carrying two hosts. Four layout tests measure the strip and the three panels at the window's minimum; the vault panel binds a key to its host first, or it would measure the short shape and certify the tall one. Two flow tests cover the multi-drop's write and its refusal, and the deletion question dropping itself. manual-checks gains 7.6a for dragging a set, which no test can see for the reason 7.6 gives, and 7.7a for the gestures — the rectangle actually being painted and the tick and the fill being legible together are the two things the harness cannot look at. |
||
|
jaap-jan
|
7b616e0bb0 | Merge branch 'claude/windows-update-bar-buttons-b19b2d' | ||
|
jaap-jan
|
36b8a23020 |
Give the update banner the view model it is typed to
The banner has never worked. It went into MainWindow's fourth row with no data context of its own, so it inherited the shell's — and it is the one control in that file typed to a screen's view model rather than to MainWindowViewModel, because it is the only one with a layout suite that hosts it over UpdateViewModel alone. Compiled bindings type-check against x:DataType at runtime, so every binding inside it resolved against the wrong object and failed the way a compiled binding does: quietly. No headline, and DismissBannerCommand and RestartNowCommand both null. A button with a null command is enabled, hovers, depresses and does nothing, which is why this looked like a hit-testing problem and why the WebView was the first suspect. It is not one. The strip is a sibling row for the reason the occlusion rule gives and that arrangement is correct — the terminal's rectangle is never covered, only shortened. What was actually on offer was an announcement that an update had been downloaded, with two buttons that refused to install it and no way to make it go away either. The preferences screen's RESTART NOW worked throughout, because it binds Updates.RestartNowCommand from the shell's own context, which is the contrast that pins the cause. The context is set on the banner itself and IsVisible loses its Updates. prefix with it, because a data context on an element resolves that element's other bindings too — the rule the page area's wrappers upstairs exist to work around. Those wrappers are needed because IsHostsScreen and its siblings belong to the shell; IsBannerShowing belongs to the banner's own view model, so there is nothing to wrap here. Neither existing suite could have caught it. A layout test supplies the data context it is measuring, which is exactly the assumption that was wrong, and the shell suite has no visual tree — its project file already says it does not cover whether the XAML binds to the right names. So the new test asserts the wiring rather than the layout: a real shell over the ready-update fake, MainWindow constructed and never shown, and the banner asked what context it got, whether it is visible and whether RESTART NOW carries a command. Checked failing with the one attribute removed. Constructing the window is safe where showing it is not, and nothing here needs it shown: a data context propagates when it is set, not when the tree is measured. |
||
|
jaap-jan
|
1e8a1f2e83 | Merge branch 'claude/trust-connect-popup-56abec' | ||
|
jaap-jan
|
4f9faa2fe3 |
Ask about a host key where the connection was made, not on the host list
The trust prompt was two banners at the top of the desktop's hosts screen, so the shell navigated there before letting a handshake raise one: Screen = Hosts, Surface = Page, in OnVaultConnectionFailed and again in the palette's own connect. The reason was sound — a connection can be started from Ctrl+K on any screen, and a question behind whatever somebody is looking at is a question nobody can answer — and it was answered the wrong way round. Rather than making the decision reachable from where the user is, it moved the user to where the decision was, and charged every screen for it. It is worst for the one connection that has no host at all. A machine typed into the phone's connect box is deliberately in no keychain, so a first contact from there judged it on a list it does not appear on, after taking the box that dialled it away. So both heads now draw the decision over the surface. HostKeyCard is the desktop's, and is the counterpart of the phone's HostKeySheet: a scrim with no press handler, because a question with two named answers must not be answerable by missing; the unknown key offering TRUST AND CONNECT, because judging a fingerprint against what an operator published is a decision a person is entitled to make and the only moment they can make it; and the changed key offering no way forward at all, because a button beside that warning is "continue anyway" with two clicks instead of one. The phone needed no new markup — its sheet was already a shell-level overlay, so deleting the navigation is what puts it over the Connections screen. IsHostKeyDecisionShowing is on the shell rather than on a screen because the answer decides an occlusion. A second connection can be refused while a first one is open, so this card is routinely raised over a live terminal, and that rectangle is a native child window: layered over it the card would be sliced at its left edge with TRUST AND CONNECT taking no clicks, which for the most safety-critical question in the product is the worst place for that class of bug to land. IsTerminalShowing gives the rectangle up instead. The banners are gone rather than copied. One prompt in two markups is two copies of the most safety-critical wording here, and the second is the one that goes stale. TWO DEFECTS FOUND BEHIND IT. VaultViewModel.RejectHostKey cleared only the pending key and never the mismatch, so the changed-key refusal had no working exit. That was invisible for as long as it was a banner nothing was drawn over — nothing was trapped, and the next attempt cleared it — and it was already live on the phone, where that refusal is an opaque full-screen panel whose one button runs this command: pressing it left the panel up over every screen the user went to next, including the host editor the panel tells them to open. TransfersViewModel.RejectHostKey has always cleared both; the vault's was the outlier. Its button said BACK TO HOSTS, which was wrong twice over, and now says BACK. And an assertion written for this change could not fail: the palette test asserted the renderer was collapsed in a scenario whose only tab had just been removed, so it was collapsed for want of a session whatever the occlusion rule said. It is gone, with a note pointing at the test that can fail on it. VERIFIED. 1580 tests, build clean, no new warnings, format clean. Three mutations each seen to fail and then seen green again: dropping !IsHostKeyDecisionShowing from IsTerminalShowing, caught by AChangedHostKey_CollapsesTheTerminalItIsRefusedOver; reverting RejectHostKey to clear one flag, caught by RefusingAHostKeyDecision_TakesItOffTheScreen(false) and by that same test; and dropping the two host-key arms from OnVaultPropertyChanged, caught by TheHostKeyDecision_IsAnnouncedToTheWindowWhenItArrivesAndWhenItGoes. That last one is the first test in this repository to watch PropertyChanged, and it is worth being the first: every other assertion about the flag reads it directly, and a direct read passes with the subscription deleted — while the card would never go away. The two layout tests moved with the prompts, from the hosts screen to the card. manual-checks gains 7.4a for the occlusion, 7.4b for getting out of a refusal and 11.7a for the hand-typed case, none of which a test can see; 1.5 and 7.4 are corrected rather than left describing a window that no longer moves. ONE ROUGH EDGE, DELIBERATELY LEFT. On the desktop, refusing a first contact whose tab was the only one leaves the terminal surface with no tabs — a blank rectangle under the strip's "no terminals open · press + or Ctrl+K", which is the one sentence near that rectangle Avalonia can draw. The alternative was falling back to the page, and on the phone that means the host list, which is the bug this commit is about. A desktop connect page would close it properly. |
||
|
jaap-jan
|
e750ba05e3 | Merge branch 'claude/edit-screen-refresh-items-63a808' | ||
|
jaap-jan
|
6d6edb02c1 |
Keep an open editor's pickers in step with the vault
The host editor's four pickers were snapshots taken when it opened, and the comment on EditorAuthenticationChoices said why: a picker whose contents move under somebody halfway through a form is worse than a list a minute stale, and only one editor could be open at a time anyway, so the only way to add a key was to close this one. The second half of that stopped being true when AHostEditorIsInTheWay was split from AVaultEditorIsInTheWay. The host editor is the Hosts screen's business and the keychain's editors are the Vault screen's; neither refuses the other now, which was the right split — it stopped three quarters of a screen going inert over an editor the user was not looking at — but it left the assumption those snapshots rested on false and nothing to notice. So the ordinary way of using the feature was the broken one. Somebody starts editing a host, finds there is no key to bind it to, goes to KEYS, makes one, and comes back to a picker that does not have it — with the fix being to throw the form away and start again. The same for a password, a tag, a group, and for a whole vault made on the Teams screen because the host being typed belongs to the team rather than to the person typing it: the vault they had just made for it was the one place they could not file it. RefreshOpenEditors refills whichever editor is open, and it hangs off ReloadAsync rather than off the twenty-odd commands that write to the vault. That is the choice worth stating, because it is what makes a sync count as well as a save: a key pulled from another machine reaches the open editor by the same path a key typed here does, and a place that wrote to the vault without refreshing the editor would be a bug nobody would find for months. What the old comment was protecting against is real, so every picker is put back onto what it was already showing, by id, and not one typed field is touched. An editor that reset its own bindings because a background sync landed would be a worse bug than the stale list this fixes — it would rebind a host as a side effect of somebody else's work. The placeholder entries go back too, which is the case 3.4 measures: a group deleted on another machine mid-edit still cannot unfile the host when the form is saved. The group editor gets the same treatment for the same reasons; it shares the drawer, and its default binding is lent to every host under it. The snippet editor's vault picker was the same copy of the same list and went stale the same way. It watches TargetVaults rather than the reload, because that screen has always been a wrapper over the vault's collections and has no reload of its own to hang off — which is how it already follows Snippets. The move panels are deliberately left alone. A vault arriving from a sync while one is open still will not appear in it, but a move panel is opened by the act that fills it and its picker resets its selection to the first entry on every rebuild, so refreshing it would move a destination somebody had chosen. Same class of bug, different answer, and not this change. Five tests, and four of them were checked failing with the RefreshOpenEditors call commented out: a key reaching the open host editor and binding when chosen, an item arriving without moving a selection that was already made, a tag arriving as an unworn chip, a key reaching the group editor, and a vault reaching the host and snippet editors without moving either. Manual check 7.12 sits beside 7.11, which is this same bug on the files screen's picker, and says what the worse failure would look like: a picker that moves rather than one that does not notice. |
||
|
jaap-jan
|
808a9a7fc1 |
Open a new host in the vault of the group it is being made in
+ NEW HOST decided two defaults separately and let them contradict each other. The group came from the screen — the selected card, or failing that the group whose contents are showing — and the vault came from the keychain screen's standing "new items go to" preference. Inside a group belonging to any other vault the two disagreed, and the group is what lost: GroupInEditingVault drops a group the editor's vault has not got, on the sound reasoning that a host filed under an id its readers cannot resolve looks unfiled to everybody but the person who wrote it. So pressing the button while standing inside a team's PLATFORM opened a form filed under nothing, bound for the personal vault, with no sentence anywhere saying either thing had happened. The vault now follows the group. A group lives in exactly one vault, so a host that is to land in that group has to be sealed in that vault too — which is the rule + NEW GROUP has followed for a parent since the cards became a tree, and the comment there claiming this as a deliberate difference from the host's editor is the one the code has now caught up with. The filter stays, because there is one case left for it: the group's vault may be one this session can read and not write, a team vault this account is a viewer of. TargetVaults is the readable-and-writable set and is what decides here, so a viewer keeps the standing preference and loses the group with it, rather than opening an editor aimed at a save that cannot happen. Both directions are tested, since one alone would not say which default wins: standing in a shared vault's group, the editor opens on that vault with the group selected and the host saves there; and with the preference pointed at the shared vault while a personal-vault group is open, the group beats the picker somebody set once. |
||
|
jaap-jan
|
f1d6499bb5 |
Merge branch 'main'
Two of main's changes land in files this branch rewrote, and both needed carrying across by hand rather than by the merge. The phone's nav staying up on Connections with nothing running is a fourth input to RefreshChrome, which this branch had already given two more — whether hosts are ticked and whether the host editor is filling the screen. They compose: the rail and the bottom bar now ask (pages || connectPage) && !editing, so a page-shaped terminal surface keeps its way off the screen and the editor still takes the whole display. The key question under the host's move panel is the harder one, because this branch deleted the panel it was added to. The connect card is gone and the phone's only route to a move is the action bar, so leaving the merge to take this side would have removed a capability main had just shipped — silently, since nothing would fail to build. It is asked in the action bar's own picker instead, in two shapes fewer than the desktop's: one host, because which key to carry is a fact about one machine and a selection of six has six answers, and a move rather than a copy, because taking the key out from under an original that is staying put would leave that original unable to connect. BindingOfTheMovingHost splits into MovableBindingOf so both heads answer it the same way from different panels. Main also fixed a real trap in the same commit — a host that only inherited its key from its group arrived in the destination naming nothing at all, because the group stays behind — and the batch move had the same bug for the same reason. It goes through Detached now, which is where that fix lives. The carried host is written as the carry left it rather than being detached again, which is the one thing worth measuring: the key takes a new id over there, so a run that rebuilt the payload from the row would send the machine across naming a tombstone. Both directions are pinned, along with the rule about which shapes the question is asked in at all. |
||
|
jaap-jan
|
c882fa0cd3 |
Give the phone a selection instead of a card under the list
A long press on a host raised a connect card over the bottom of the list: a password box, CONNECT, EDIT, MOVE and DELETE. It was the right idea in the wrong place. It covered rows, it had room for five things and never a sixth, and every one of them was about exactly one machine — so filing eleven imported hosts under a group was eleven trips through a form, and there was nowhere to put a sixth action if anybody wanted one. A long press now chooses the host it landed on, and the actions move into a bar across the top of the screen, in the vault header's place rather than beside it. That is where Android has put them since contextual action bars existed, and it is the one strip a list can never grow into — but the real reason for it is that while it is up the screen is unambiguously about the ticked hosts and nothing else, which is what lets the count in the middle of it mean something. Left to right: the cross that leaves the mode, the count, the pencil, and a ⋯ holding Connect, Connect via SFTP, Move to vault, Copy to vault, Change group, Duplicate and Remove. A tap still connects and still raises nothing. Once anything is ticked it ticks and unticks instead, which is what every Android list does and is not merely a convention worth following: a tap that connected while five machines sat ticked would open a terminal on top of a selection somebody was halfway through building. Unticking the last host leaves the mode, so there are two ways out of it and the cross is only one of them. Both gestures now read the row from the element under the finger rather than from the list's selection, and that is a correctness change rather than tidying. A tap on a group heading moves the selection and the view model bounces it straight back to whichever host was chosen before — which answered "a host, or nothing" for free while a tap only ever connected. It stops answering it the moment a tap can tick one: the heading would tick a machine the user was not pointing at, into a set they are about to delete. Three of the seven entries are about one machine and are drawn only for one. A terminal, a file-transfer session and a form each have no reading over six, so they are collapsed rather than refused. The other four read better for a count than without one — it is the reason the set exists — and each of them says afterwards how many hosts it wrote and how many it left alone. Skipping beats refusing the whole run: a selection of eleven with one read-only row would otherwise do nothing at all and then report about the wrong ten. Copy to vault and Duplicate are new, and the difference between them is what each can safely carry. A copy crosses a key boundary, so it drops the group and the tags exactly as a move does — both are items of the vault being left, and a host arriving with either would point at something the destination does not contain, resolvable on the machine that sent it and dangling for everybody else. A duplicate stays in the same keychain, so everything it points at is still there and it keeps both. Change group is the write dragging a card onto a group already makes on the desktop, run over a selection; it refuses one spanning two keychains rather than half-filing it, which is the refusal a drop across that boundary already makes one host at a time. Connect via SFTP is the one action that leaves the vault. Which machine is a decrypted item and so is this object's business; the screen it leads to and the transfers view model behind it are the shell's — so it is an event, on the same division SessionOpened already draws for a shell. The host is re-found in that screen's own copy of the list, because the picker binds to rows in that copy and handing it the vault's object would select nothing. What is left of the card is the password box, and only because it had nowhere else to go: a host that authenticates with a typed password cannot be reached by a tap alone. That tap now raises a sheet rather than the bar, and the difference is that a sheet is up only while a question is on screen — the bar was raised by a long press and stayed, so it was a password box sitting over the list whether or not anything was being asked. Dismissing it empties the box, which is not tidiness either: a secret left behind would satisfy the emptiness check that decides whether to raise the sheet at all, so the next tap would dial with somebody else's password. The pencil moving into that bar takes the host editor with it. It was a card in the list's own row, under the search box and the sync line — twenty controls sharing a screen with two rows of chrome about the list it had replaced. It is a page now, and PhoneShell stands all four of its rows down for it, which is what "opens with all the options" means at 360dp. That needed a second subscription in that control: two of its flags are questions about the vault rather than about the shell, and the shell does not forward the vault's notifications. The ticks are held as entity ids rather than as rows, and written back onto the rows after every reload. Every row object in the list is replaced on every filter keystroke and every synchronisation pass, so a set of rows would empty itself once a minute under somebody choosing what to do with eleven machines. Ids that no longer resolve are dropped, so a colleague's deletion arriving mid-selection leaves a count that matches what is on screen. One caller had to change with it. ConnectToRecent opened the pane about a host, which was the desktop's drawer and the phone's card; the phone's answer is now a tick, and nothing on that list means "selected" any more — so arriving with the host merely selected would be arriving at a screen with nothing to press. Both are raised together, and the one the head in front of the user does not draw is inert. |
||
|
jaap-jan
|
69858f82d1 | Merge branch 'claude/vault-key-sync-sharing-d098aa' | ||
|
jaap-jan
|
509a7c34f5 | Merge branch 'claude/snippets-vault-sharing-470476' | ||
|
jaap-jan
|
185790fb14 |
Let a key move to another vault, and ask whether it goes with the host
Keys sync and keys are shared: SshKey is in the sync registry on both sides, the material rides in the sealed payload, and every generation of the vault key is wrapped to a new member. What was missing was the way in. Hosts and groups could move between vaults and keychain items could not, so a key typed into a personal vault before the team existed stayed there for good — and moving a host into the team's vault left it authenticating with something nobody else in that vault can read. The code said so and could do nothing about it: "the answer is usually to put a copy of that key in the destination vault", which meant pasting the private half into a second item and deleting the first. A private key on a clipboard, and two items nobody can tell apart afterwards. MoveAsync already existed on the generic repository and is now exposed for keys and passwords as it is for hosts and groups. What had to be built around it is the re-aim. An item re-sealed under another vault's key lands with an id of that vault's making, so every host bound to the old one and every group lending it as a default is left naming a tombstone — and a host bound to something its vault no longer holds refuses to connect rather than falling back to a typed password. A move without the re-aim would look like a success and break every machine on that key. It runs over every vault this session can write to, because a binding resolves across all of them, and it counts what it could not rewrite: an item from a newer client, or one in a vault this account may only read. Those are said in the sentence afterwards rather than swallowed. The host's move asks the question rather than deciding it. A binding resolves across vaults, so the moved host goes on working for the person who moved it whichever way this is answered; it is the colleagues they have just joined who hold one vault's key and cannot connect with a host whose key stayed behind. Unticked, and it stays that way on purpose: moving a key into a team's vault hands it to everybody holding that key, and this design does not default anybody into a disclosure. Under the box is the count of everything else that authenticates with that key, because a key twenty machines use is a different decision from one nothing else touches, and neither number is visible from the panel otherwise. The question is answered against the vault in the picker, so choosing a different destination re-asks it and a key already in the destination offers nothing. One thing fixed on the way. A host that inherited its key from its group arrived in the destination naming nothing at all — the group belongs to the vault it left — so a machine that connected before the move refused after it, with no sentence anywhere saying why. The resolved binding is now written onto the host as it crosses, and the stranded-binding warning reads the resolved binding too, which is the case where somebody is least likely to know a key is involved. MOVE is on both heads, for keys and passwords only: a tag, a bucket and a pin are read from the active vault alone, so "another vault" is not a question any of them has. Four tests cover the move and its re-aim, the host's move with the key brought and without it, and the inherited binding. |
||
|
jaap-jan
|
3d9ed03b09 |
Let a snippet be shared to a vault, the way a host already can
A snippet was a first-class vault item everywhere except where it mattered: the crypto, the sync, the server table and every registry already treated it exactly as they treat a host, and the screen read it out of the active vault alone. So the one command a team most obviously wants to hold in common — the incantation somebody worked out once and everybody else retypes — was the only item kind that could not leave the machine that wrote it. The read is the half that had to come first, and it is why this is not simply a MoveAsync. ReloadSnippetsAsync now lists every readable vault rather than the active one, in the shape ReloadHostsAsync and ReloadKeysAsync already use: the vault new items go into first, then by vault name, then by label, with a badge on the row only where there is more than one vault to tell apart. Without that, a snippet moved into a team vault would have disappeared from the very screen that moved it, and one a colleague wrote there would never have arrived at all — sharing would have looked like losing. Three writes were pinned to the active vault and each one broke differently once the list spanned several. The delete tombstoned in the wrong vault, which tombstones nothing and leaves the snippet on screen. The save is the bad one: an update sent to the active vault creates a second snippet there and leaves the team original untouched, so the person editing sees their fix and nobody else ever does. That is a fork with no symptom, which is why the vault is now a parameter and the screen latches it when the editor opens — the chosen vault for a new snippet, the row own vault for an existing one — rather than reading it back off a selection that can move under a half-typed form. VaultViewModel has carried editingHostVaultId for the same reason since hosts crossed vaults. Two controls rather than one, and that is the same line the host pane draws. The editor asks which vault a new snippet is filed into; MOVE re-seals an existing one under another key and tombstones the first. Putting the second inside the first would let somebody correcting a typo hand a command to a team by leaving a picker where they found it, so the picker is not drawn for an existing snippet at all. Both live on SnippetsViewModel rather than VaultViewModel because this screen owns its editor, unlike the host drawer; the writing they ask for is still the vault. A snippet crosses whole, which is the one way this is simpler than the host it copies. A host leaves its group and its tags behind because both are items of the vault it came from and would dangle for everybody in the destination. A snippet is a label, a command and a note, and none of them points at anything — so there is nothing to strip, nothing to report as left behind, and what the copy says instead is the thing that is actually at stake: who can read the command afterwards. For a command that may carry a hostname or a path, that is the whole decision. Two judgement calls worth finding later. A hidden vault now hides its snippets, filtered in the screen projection rather than in VaultViewModel.Snippets, which is the rule keys and passwords already follow: the list stays whole so nothing that resolves against it breaks, and the projection is what a preference about reading gets to change. And the nav rail count is left spanning vaults unfiltered, because Vault.Hosts.Count beside it is unfiltered too — filtering one of the four would make the rail disagree with itself. Four flow tests in VaultSharingTests, beside the host ones they mirror: the move re-seals with a new id and carries the runs-on-insert flag across, the move with nowhere to go refuses rather than opening an empty picker, the editor files into the vault chosen on it, and the edit of a shared snippet goes back to its own vault instead of forking. That last one is the regression the latch exists for and the only one whose absence has no visible symptom. Plus a layout test with the move panel open, since that paragraph wraps in a 300-pixel column and the desktop pane it lands in is measured. The whole suite passes: 1660 tests, none failing. |
||
|
jaap-jan
|
cddfeb1f55 |
Keep the phone's nav under Connections when nothing is running
The chrome stands down for a shell, and it was standing down for the whole terminal surface. Those parted company when that surface gained a connect page: with no tabs open it draws a box, a CONNECT button and the machines connected to before, which is a page in everything but which enum it is in. A third of the display is worth giving to a shell and is not worth giving to that. Worse, it is the one screen somebody arrives at by closing their last tab — so the state the collapsed bar was most likely to be seen in was the state where it left the system back gesture as the only route to Hosts or Settings. So RefreshChrome reads one more question. IsTerminalSurface with no tabs joins the pages in both flags, which keeps the rail and the bar in step: above 600dp the rail is the bar, and fixing only the narrow layout would leave an unfolded device on the same screen with the same nothing. The vault header is deliberately not part of it. The surface draws its own bar with back and the +, and a header above that is the second row of chrome this head exists to avoid. The Connections entry lights for the first time, on IsTerminalSurface. It was left unbound on the argument that the bar was never drawn while that surface was up, so a lit state was unreachable — that argument is now false, and the flag is unambiguous on a control that is only drawn in two situations: false on every page, true on the connect page, and never read while a shell is showing. A bar sitting under a screen it does not point at is the entry looking broken instead. Nothing here is testable on this head — the phone's rectangles have no coverage, for the reasons Phase 8 of manual-checks records — so 11.7 gains the check that the bar is there with Connections lit, and 11.1 keeps the one that it is gone with a shell up, which is the half that pays for the arrangement. |
||
|
jaap-jan
|
174ef7c420 | Merge branch 'claude/android-release' | ||
|
jaap-jan
|
af0e29a98b |
Give the desktop a nightly channel, the way the phone has one
ADR 0014 gave the phone a nightly and ADR 0013 rule 3 gave the desktop none, so the two heads had different answers to the same question — how does somebody try what is on main? — for no reason except the order the work happened in. This is the desktop's answer: CI publishes a build from main on every push, and it installs beside the release one rather than over it. The phone gets its separation from the platform. Android refuses an update signed by a different key, so its two channels cannot replace one another whatever anybody does. Nothing refuses anything here: Velopack applies what its feed serves and verifies no signature. So all of it is construction, and there are four separations because each closes a different door. A pack id each, so the two install in different directories and neither feed's package can be applied to the other's install. A Velopack channel each — win and win-nightly — so neither build ever reads the other's release index; the name reaches the wire as releases.win-nightly.json, which is why the constant in VelopackUpdateChannel and the argument in ci.yml have to agree or the channel answers nothing forever with no error. A prerelease flag, so the release channel cannot see the nightly even by accident. And a profile directory each, which is the one that is easy to skip and would hurt most: the cache schema is migrated on every launch, before unlock, so a shared profile means a nightly quietly upgrading a database the release build then opens. Both are installed at once by design, so that is an ordinary Tuesday rather than a corner case. The prerelease flag turns out to be load-bearing across heads as well. The phone's release channel reads releases/latest, which skips prereleases — so a desktop nightly published as a stable release would become the newest release in this repository and every phone on the release channel would start failing its check against a release carrying no Android manifest. Which build this is arrives as assembly metadata, the same mechanism and the same reasoning as the Android head: the updater needs the string rather than a branch, and a value baked into the assembly is one a crash report can be asked for. Three things read it — the feed, the prerelease flag, and the profile — and one more shows it: the titlebar says DodoSSH Nightly. Everything else that distinguishes the two is somewhere nobody is looking while typing a passphrase into one of them. The version needed a floor and it is applied to the whole build rather than to the packaging. MinVer answers 0.0.0-alpha.0.N until the first v* tag and vpk refuses anything below 0.0.1, so the job lifts the patch digit and keeps the height — through MinVerVersionOverride, so the assemblies carry the same number the installer does. Packing a version the assembly disagreed with would put one string on the preferences screen and another in the feed, which is the screen somebody reads when asked which nightly they are on. Two things found by running it rather than reading it. -t:MinVer needs a restore first, because the target arrives with the package and MSB4057 on a clean checkout reads like a typo in the workflow rather than a missing restore; the release script had the same gap and now restores before it reads. And vpk rejects an empty --packVersion loudly, which is how a broken version handoff announces itself rather than shipping a package called 1.0.0. Rule 3 is untouched. The release channel still has no job, no token and no runner, and the two channels cannot see each other. What a nightly costs is written where somebody reads it before installing one: whoever can write a release here can put a build on every nightly machine, which is fine for a build being tried and is not fine for a build holding somebody's infrastructure credentials. Verified by running the job's own steps against a clone in a Linux container: DodoSSH.Desktop.Nightly-win-nightly-Setup.exe, and an index naming pack id DodoSSH.Desktop.Nightly at 0.0.1-alpha.0.144. The upload itself is the one step not exercised — it needs a real forge and a write token, and check 16.10 is what walks the half no runner can. |
||
|
jaap-jan
|
8591035170 | Merge branch 'claude/pipeline-curl-not-found-97e70f' | ||
|
jaap-jan
|
ca7fee2358 |
Start the confirmation Android hands back, so an update can install
Pressing INSTALL closed the application, installed nothing and said nothing. That is two independent faults in one method, either of which breaks it on its own, and they hid each other: the first kills the process before the second can be observed, and the second is silent by construction. The pending intent handed to commit was implicit — an action string with no component behind it. A mutable pending intent may not wrap one of those from API 34, and this head targets 36, so every current phone threw IllegalArgumentException before commit was reached. Nothing caught it, so it left the command handler, passed the dispatcher and took the process with it. That is the closing. Below 34, where it did not throw, it still installed nothing. An application holding REQUEST_INSTALL_PACKAGES rather than the privileged INSTALL_PACKAGES gets no verdict back from a commit: what the platform answers first is STATUS_PENDING_USER_ACTION, carrying the activity that draws the dialogue in EXTRA_INTENT for the application to start. Android does not draw it on its own. The comment here asserted the opposite — that a pending intent is required whether or not anything listens, and that nothing needed to — so no receiver was ever written, and the session was written, committed and left staged forever. So there is a receiver now, not exported because the only sender is this application's own commit, and the intent naming it is explicit, which is the same change that stops the throw. Sessions are abandoned when anything fails, since one created and neither committed nor abandoned stays staged against a per-application cap — a repeating fault would have started failing at CreateSession instead, which is the same bug wearing a completely unrelated face. The reporting is the part worth keeping even after the cause is gone. Where applying ends the process an exception has nowhere to go; where it does not, which is this head's whole shape, it goes out through the dispatcher. RestartNowAsync now answers the way CheckNowAsync already did, and the regression test asserts the absence of a throw rather than the presence of one. ADR 0014 rule 6 gets the correction in place: "asks Android to ask" is one step longer than it reads. Check 17.5 needed no rewording — it asks for the installer appearing by name, which is exactly the thing that never happened — so what it gets instead is the two symptoms named, because both present as a dead button. It is the only thing in the project that can catch either, and it plainly was never run against a real pair of builds. Note for whoever takes the next nightly: a broken updater cannot install its own fix. The phone is running the code this commit replaces, so the first build carrying it has to be sideloaded by hand; the ones after that install normally. Compile-verified and manifest-verified — the receiver reaches the generated manifest — and 321 tests pass. Not run on a device, which is what 17.5 is for. |
||
|
jaap-jan
|
b4619db8d2 | Merge branch 'claude/android-release' | ||
|
jaap-jan
|
3d3d0bc95f |
Package the Windows client in CI, on the runner that could not
The build job published a win-x64 tree and stopped there, so the half of a release that fails in ways a compile cannot see was proved by nobody until a person was midway through cutting one. It now packs as well: vpk opens the published binaries and verifies the main executable really calls VelopackApp.Build().Run(), which is the check worth having — a refactor that drops that call compiles, tests green, and produces an application that silently never updates itself. The file said this was impossible on Linux, and also said it was fine, in comments forty lines apart. The claim that vpk needs Windows tooling to stamp the Setup.exe stub is the one that was wrong: vpk cross-compiles when told to, and the telling is a bracketed directive before the verb rather than a flag. Plain `vpk pack --runtime win-x64` on a Linux host refuses outright and says so in the message that names the fix. `[win]` must be quoted, or the shell reads it as a glob matching any one of w, i and n. Only signing needs Windows, and nothing here is signed yet. Fixing that does not move ADR 0013 rule 3 an inch, which is why the two reasons were recorded separately in the first place. What may not live on a runner is the token, not the build: Velopack clients apply what their feed serves without verifying a signature, so whoever can write a release can ship an update every install runs. The packages go to RUNNER_TEMP and die with the job. They are not offered as workflow artefacts either — an installer nobody has run should not sit somewhere that invites passing it on. Written out as shell rather than by calling scripts/release-windows.ps1. That script is a person's procedure and holds things a runner must not have and must not skip: it refuses a dirty tree, insists HEAD is tagged, downloads the previous release for deltas, and asks for the forge token. Calling it would mean either weakening it with CI switches or having CI satisfy conditions that only make sense at a desk. The constants the two now share — pack id, title, authors, channel, icon — are a contract with VelopackUpdateChannel and with every installed client, and both sides say so. Two things fell out of running the steps rather than reading them, and both were in code nothing had ever executed: dotnet msbuild -getProperty:Version answers 1.0.0. Without a target named it evaluates the project and runs nothing, and MinVer computes inside a target — so the read comes back as the SDK default on a full checkout with every tag present. That line is the tag check in this file, which is `if:` a tag ref, and there are no tags yet: the first release ever cut would have been refused by its own guard, which would then have blamed fetch-depth. release-windows.ps1 had the same line and would have demanded HEAD be tagged v1.0.0. Both now pass -t:MinVer. And MinVer answers 0.0.0-alpha.0.N until that first tag exists, which vpk rejects outright as below 0.0.1 — so packing the true version could not have worked on any build made today. The patch digit is lifted for the throwaway package only. The release script gets no such floor and must not: its version is the one users compare against, and there the refusal is the right outcome. Verified by extracting both steps from this file and running them against a real clone in a dotnet SDK container: Setup.exe, the portable zip, the .nupkg and releases.win.json, from a machine that is not Windows. |
||
|
jaap-jan
|
205f946450 |
Give the nightly's publisher a curl to publish with
The android job builds its APK in a glibc container and then does the publishing on the host, and the host is Alpine — busybox wget, and no curl anywhere on it. So the step that talks to the forge six times died on the first of those calls not written to tolerate a failure, with `curl: command not found` and exit 127, after the whole build had already been paid for. It took until the fourth call to say so, and that is the part worth reading. The lookup for an existing release and the tag delete before it both end in `|| true` with stderr discarded, which is exactly right for "there is no nightly yet" and indistinguishable from "there is no curl on this machine". Installing it is what makes those two different again. Dropping the `|| true` instead would fail the step on the first run of a channel that has never published, which is the one state that shape is there to handle. Not busybox wget in curl's place. The asset upload is a multipart -F, which busybox wget cannot send — so that reading ends in a release created with no APK on it, which is the failure the verification at the end of the step exists to catch, arrived at on purpose this time. Conditioned exactly like the step it serves, main only, because nothing else in this job wants curl and a pull request should not pay for a package it will not use. That is a coupling rather than a tidiness, and it is in the comment: the two conditions have to move together, and loosening the publish on its own puts the job back at exit 127 several minutes in. Unproven until the next main build, since the install path only runs there. What is checked is that the workflow still parses, that the script is valid under sh as well as bash like the ensure steps beside it, and that the two conditions read identically once parsed. |
||
|
jaap-jan
|
5cb361ea13 |
Lay the phone out like the desktop when the surface is not a phone
Three destinations in a bar and everything else behind SETTINGS is the right shape at 360dp, where a fourth entry costs the width of the three that are there. On a tablet, an unfolded foldable or a landscape phone it is the wrong one: there is room for every destination at once, and the hub becomes an extra tap between somebody and a screen they can already see space for. So at 600dp — Android's own boundary between a compact window and a medium one, in the density-independent units Avalonia lays out in — the bar stands down and PhoneRail takes the left edge with all nine on it. It is the desktop's NavRail arrangement rather than its file: the two heads cannot share a view, and this one draws the phone's destination set with the phone's palette and touch targets. The flags are computed in code rather than assembled in the markup because none of them is a single question any more, and Avalonia's bindings have no "and" — and the header's condition is an "or", which not even a wrapper can express. That header is the one worth reading twice: narrow it stands down behind SETTINGS, so the hub's screens can draw their own; wide there is no hub to be behind, so it stays up everywhere. Losing it on the keychain would be losing the only LOCK button on the surface. Removing the hub means removing the routes into it, and there were four kinds. The rail has no SETTINGS entry, because that screen is a menu of the rail. The five back arrows in the screens under it are hidden, since an arrow to a screen the layout removed is the one control on a header that leads nowhere. The system back gesture goes to Hosts instead. And unfolding while sitting on the hub moves to Hosts, rather than leaving somebody on a list of things now visible beside it. One bug fixed on the way: OnBodyResized returned early unless the keyboard was open, so a foldable would have opened to a phone layout until somebody typed something. The chrome is refreshed first and unconditionally; the early return belongs to the older job below it. What this does not do is use the width *inside* a screen — the host list is one column at any size. Two columns needs the row model to change, because that list is headings and hosts in one sequence and a heading has to span, and that model is shared with the desktop. Check 8.1 walks the rail; nothing here is covered by a test, for the reason 8.0 exists. |
||
|
jaap-jan
|
0c61ea3a97 |
Let a vault be shared from the phone, not only read there
This screen's own comment argued ADD out: an address typed into a box, a directory lookup, a role picker and a paragraph saying what adding somebody did not do, for an act a colleague at a desktop is already performing. That was a cost argument and it was wrong about who is holding what. The person who needs to let somebody into a vault is often the one away from their desk, and answering them with "go and find a desktop" is the thing this head exists to stop doing. Making a vault was already here on exactly that reasoning. Nothing shared changed — AddMemberCommand, the role and the chips are the same members the desktop binds — so what this is, is markup and the argument it reverses. Four rows under the members list: the box, three role chips rather than a picker because the answer is one of three short words, ADD, and the paragraph. Gated on being able to administer the vault, so a plain member sees nothing rather than a button whose only outcome is a 403. The paragraph is not the optional part. Adding somebody changes what the server will serve and nothing else; the key is still wrapped by a machine that holds one — which on an unlocked phone is this one, in the same press. A screen that offered the first and stayed quiet about the second would imply the server can hand out access, which is the single claim this product is built to refuse. What the phone still does not draw is anything that takes access away. REMOVE and WITHDRAW KEY act on the first press, and an irreversible revocation under a thumb with its explanation in a tooltip no touch screen can show is the wrong trade — which is the line this file already drew and this does not move. Check 12.4 walks it, including the locked-keychain case: the membership is made and the line says the key could not be wrapped, which is a state somebody can act on rather than silence. |
||
|
jaap-jan
|
dc1ebf6afa |
Let the recovery code be copied, and give the phone a clipboard to copy to
Both screens had made the code selectable and both said why: a person who cannot get it out of the box photographs the screen, and a screenshot is a worse home for it than a clipboard. This finishes that argument. Selecting 64 characters of letter-spaced monospace with a thumb is the version of "possible" people give up on halfway — and on the phone the screen blocks screenshots, so the honest remaining options were retyping it or losing it. It is the one secret this application deliberately offers to a clipboard, and the contrast with the keychain's copy is the whole argument rather than an inconsistency. There, copying the private half is refused outright, because installing a key means pasting the public one and the private one has no business leaving the vault. Here there is no better route: the code exists for one screen, is stored nowhere, and has to reach a password manager. The clipboard is the intended destination rather than a way round the design. The sentence afterwards matters as much as the copy, and is asserted: a clipboard is a staging post, this screen is the only place the code exists, and the next thing copied replaces it. Somebody who copies and does nothing has not saved it. The phone had no clipboard delegate at all — the desktop passed one and this head passed null — so COPY PUBLIC KEY on the keychain answered "this machine has no clipboard" on a device that plainly has one. Nothing about that was platform shaped: Android has a clipboard and Avalonia surfaces it through the same TopLevel. Wiring it fixes that copy too. The test fixture built its shell without a clipboard, which modelled the bug rather than the product, so it has one now and the public-key test asserts what lands there instead of the refusal. The refusal keeps its own test, on a shell built without one, because the view model reads the delegate's absence rather than an empty result — and because a button that silently does nothing on this screen is worse than one that refuses. |
||
|
jaap-jan
|
253c72d2b7 |
Name the organisation the repository actually lives in
It moved to DodoTech-Public, and every address in the product still said DodoTech. That looked like it worked, which is the part worth writing down: Gitea leaves a 301 at the old path and HttpClient follows a redirect on a GET, so both update channels would have kept polling through it. What a 301 does not survive is a POST. `vpk upload gitea` publishes the desktop release by POSTing to that URL, so the stale address would have failed at the one step the whole feature depends on — and a redirect is a thing an operator can delete, which turns "works today" into the same silent outage this session has already spent two commits on. So both channel constants, both release scripts, the workflow's REPO, the image's source label and the curl in phase 16 all name the live path. The local remote too, which had been printing a redirect warning on every push. Measured after the move: the org, the repo and the nightly release all answer 200 anonymously, and that release now carries both assets — the manifest and a 54 MB APK. The upload going through also answers the open question about the reverse proxy's body-size limit, which nothing local could test. |
||
|
jaap-jan
|
23f1db9dc8 |
Stop the terminal's accessory keys taking the keyboard off it
Ctrl, Esc, Tab, the arrows and the two text-size keys were ordinary Avalonia buttons sitting over a NativeWebView. An ordinary button takes focus on tap, which takes it off the WebView — and the package's own OnLostFocus then calls the adapter's ResignFocus(). So pressing Tab handed the terminal one byte and took the keyboard away from it, and everything typed afterwards went nowhere. What makes it worth more than a one-line fix is the symptom. The row goes on working, because its keys are pressed rather than typed into, so what you see is a terminal that answers the buttons and ignores the keyboard — which reads as the session having died rather than as anything to do with focus. Focusable = false is what a toolbar button is: these keys are an extension of the keyboard, not a place it should go. The focused element then never changes, so nothing resigns and nothing has to be handed back — which matters, because the hand-back is the direction platform-flags already records as the hard one. The flags file gains the phone's half of that entry, and check 11.10 is the measurement: this needs a paired hardware keyboard and there is no test on this head that could stand in for one. |
||
|
jaap-jan
|
1bcf422bbe |
Build the phone once per run, and stop rebuilding the toolchain image
The android job compiled everything twice. The plain `dotnet build` before the packaging step looked like a cheap check ahead of an expensive one and was neither: SignAndroidPackage depends on Build, so the packaging line compiles everything anyway — and the build above it ran with no -p:DodoChannel, which means it ran as the *release* channel. Different application id, different version, different assembly metadata; MSBuild treats a different set of global properties as a different project instance, so not one output was reused. It was a full second compile of the reference closure, producing an APK for the one channel this job must never build, thrown away unread. Measured in the toolchain image with a warm package volume, same commit: two builds 2m52 + 2m26 5m21 total one build 3m01 3m04 total Byte for byte the same artefact out of both — versionCode 203, versionName 0.0.0-alpha.0.136, dev.dodotech.dodossh.nightly. The toolchain image is now built once per Dockerfile rather than once per run. The tag is the Dockerfile's own digest and docker applies a tag only on success, so an existing tag is by construction the right image and `docker image inspect` is a sound check rather than a guess. What that trades away is the JDK from apt drifting; everything that decides what is in the image is pinned in the Dockerfile, so anything that matters changes the digest. It is a build tool, not something shipped — the image job takes the opposite trade with --pull, because what it builds is what users run. And the build job now says whether its package cache did anything. setup-dotnet's cache: true is actions/cache underneath, which needs a cache server act_runner ships and can have turned off — and when it is off it does nothing and says nothing about it. A cold restore and a perfect cache look identical from outside: both are green, and the difference is minutes. One `find` before anything writes to the folder turns that from a belief into a line in the log. It does not fail the build, because a runner without a cache server is slow rather than wrong. What is deliberately not cached: the apt installs in each job's preamble, which need the runner's image fixed rather than a workflow change and already say so; the Testcontainers pulls and the API image's layers, which the daemon already caches on a persistent runner; and the android obj/bin, which would not help — the source arrives by `docker cp` with fresh timestamps, so MSBuild rebuilds it whatever is in there. |
||
|
jaap-jan
|
33d4c3ff48 |
Check the organisation as well, because in Gitea the organisation wins
Setting the repository public changed nothing: /api/v1/orgs/DodoTech answers 404, and a Gitea org's own visibility gates everything under it — a public repository inside a Limited or Private org is invisible to anyone not signed in. So 16.0 now checks both, and says which answer means which. It also names the signal that tells this apart from an instance requiring sign-in for everything: /explore/repos answering 200, which this one does, so what is hidden is hidden on purpose rather than by policy. |
||
|
jaap-jan
|
e0655dbb31 |
Look the host list up by name, rather than off a field that is never assigned
Nightly 0.0.0-alpha.0.133 died before its first frame. The long press I added attached itself in HostsScreen's constructor through the field the Avalonia name generator declares for `x:Name` — and that field is assigned by the generated InitializeComponent, which no view in this repository calls. Every one of them loads its XAML directly. So the field compiles, resolves in the editor, and is null at run time; PhoneShell builds this control on the way up, so the NullReferenceException took the launch rather than the hosts screen. PhoneShell and TerminalScreen both use FindControl, and PhoneShell carries a <remarks> saying exactly this and naming exactly this consequence. I read neither and wrote the field. So the rule is in docs/platform-flags.md now as well. A comment on the control that already got it right is not where somebody writing a new one is looking, which is the whole of why two correct examples and one warning were not enough. And phase 8 opens with "it launches at all". Nothing on this head is covered by a test — no test project, no headless surface — so a view that throws while being built takes the launch with it and no gate anywhere says so. Thirty seconds, and it would have caught this one before it was published. |
||
|
jaap-jan
|
9a7e3bbd5c |
Let a failed update check say so, instead of reporting good news
The phone reported every build as current because the release repository is private. Gitea answers 404 rather than 403 for a repo you cannot see, the client reads that address anonymously, and AndroidUpdateChannel caught the failure and returned null — which IUpdateChannel documented as meaning "this build is the latest". The check had never once succeeded on any phone and nothing anywhere said so. Two faults, and the second is why the first lasted. The seam said null was the honest answer for an unreachable channel, on the reasoning that the caller does the same thing either way. That is true of the six-hourly pass and false of CHECK NOW. UpdateViewModel already draws the line correctly — silent on the timer, the exception's message on the button — and it could only ever draw the first half, because nothing was ever thrown at it. The desktop's channel does not catch, so the interface described neither implementation. So CheckAsync throws now, and null means one thing. A release that is reachable but missing its manifest or the APK it names throws too: "you are up to date" about a half-published feed is the same lie in a smaller costume, and the self-healing that argument protected is untouched, since the timer still swallows everything. The precondition is written down where somebody would look, rather than left as a sentence about where a token could live. ADR 0013 §4 already said a private release repository was incompatible with this design; nobody checked which side of it this repository was on. It is one curl, and manual-checks phase 16 now opens with it — pointedly not against /api/v1/version, which answers 200 from a forge that is up whatever is readable on it, and which is what made this look like nothing was wrong. Phone check 17.4 was the one that passed all along. It now presses CHECK NOW with the network off as well as on, because two different answers are the whole of what makes the first one worth reading. |
||
|
jaap-jan
|
ca07d63585 |
Offer to bring the keys an ssh_config points at
An import that recorded a key path and left every host asking for a password was an import whose result did not connect. The answer to that was a manual paste per key, which is the sort of thing people do once and then stop importing. So there is a tick, and it starts off. With it off nothing changes: an IdentityFile becomes a note and the host asks for a password. With it on, IMPORT reads each host's first IdentityFile out of ~/.ssh, stores it in the vault encrypted like any other key, and binds the host to it. Three things about how it is drawn are load-bearing rather than tidy. It is a default nobody arrives at by accident. The sentence beside it names the directory rather than saying "your keys", because that is what somebody is agreeing to. And nothing is read during SCAN — tick it, read what it says, untick it, and no private key has been opened. This is the only place the application opens key material out of a directory the user did not point at file by file, and the whole of what makes that acceptable is that it took a deliberate press. One vault key per file, however many entries named it: an ssh_config pointing twelve hosts at one id_ed25519 is the ordinary shape, and twelve copies would be twelve things to rotate and eleven to forget. A file whose material is already in the keychain is bound to rather than stored again, which is what makes running the import twice harmless. What cannot be read off a disk is a passphrase, so a protected key arrives without one — and the report under the button names those files rather than leaving a host to fail at connect time with a message about a malformed key. Telling them apart means decoding for OpenSSH's own container, whose cipher name is the first field inside the base64 rather than anything in the armour, and that is the format ssh-keygen has written by default for years. The 88 base64 characters it decodes need 66 bytes, not 64: with the smaller span every protected key came back unprotected, which the tests now pin. A path that is not on this machine leaves its host imported and unbound, exactly as it would have been with the tick off, and is named in the same report. A config carried from another machine is the ordinary case, not an error. |
||
|
jaap-jan
|
746711da9d |
Let a tap on the phone's host list mean connect
Choosing a machine raised the connect bar over the bottom of the list: a password box, CONNECT, EDIT, MOVE and DELETE. Five controls in the way of the one thing a tap on a machine's name obviously means. So the gestures split. A tap connects. A long press raises the bar, with all five. The pencil in the phone's header — its only persistent chrome — edits whichever host is chosen, which is the one of the five common enough to be worth a control that is always in the same place. The flag doing it is the desktop's own IsHostPaneOpen rather than a second one. That head made exactly this move when a selection stopped opening its drawer, and the question both are asking is "has somebody asked about this host" — answering it twice is how two heads come to disagree about what a selection means. One tap cannot finish: a host that authenticates with a typed password has nowhere on a list to be given one. That tap raises the bar with the box in it and says so, and a second tap with the box filled in connects. The branch is in the view model rather than in the head, because "can this machine be reached without asking for anything" is the same question the bar's own password box answers, and a copy of it in a view would be a second reading of a binding chain that has one. Two mechanics worth knowing. Avalonia raises Tapped on release whatever the press lasted, so a long press would open the bar and then connect — one touch firing both gestures — which is why HostsScreen tracks the hold and swallows the tap it precedes. And Holding only fires once IsHoldingEnabled is set, so that and the handler are attached together rather than one in markup and one in code. ConnectToRecent now opens the pane rather than selecting the row. On the phone it has to: a selection alone raises nothing now, so going back to a recent machine would land on a screen with nothing to press. |
||
|
jaap-jan
|
69bc9e270b |
Let a team be joined only by somebody who is already here
An invitation decided access from an assertion about an address. Everything else
in this model decides it from something a person did — an admin naming an
account, a key holder wrapping a vault key to a key they verified — and this was
the one place a token's email claim was the thing that let somebody in.
It was guarded as tightly as that can be guarded: the claim was refused outright
on an unverified or absent `email_verified`, with no setting to relax it. But the
guard and the risk were the same shape. The whole defence was one boolean sent by
a system the deployment does not control.
So `POST /teams/{id}/members` is the only way in, and an address with no account
is refused with `no-such-account` — which is now the end of the road rather than
the signal to invite. Both clients say the remedy: that person signs in here
once, which is what creates the account, and then they can be added. The desktop
leaves the address in the box, because a message telling you to come back later
is one you act on later.
Gone with it: the `team_invitation` table, the claim hook in the sign-in path,
and `Oidc:EmailVerifiedClaim`, which that hook was the only reader of. Nothing in
the server now reads the email claim to decide anything.
Pending invitations are dropped rather than converted. Converting one would mean
creating a membership because an address matched, which is the property being
removed — and an invitation to an address that did have an account here had
already been claimed by the hourly sweep, so what is left is offers to people who
never arrived.
Two tests carry the property rather than the feature: the endpoint inventory
asserts the three routes are absent, and the API suite adds an address that has
no account, watches the refusal, then signs that address in and checks it joined
nothing. Without the second half, a server that merely renamed the deferred path
would pass.
|