Public Access
Free the terminal from the Hosts screen, and fill the room it left
The WebView sat inside the Hosts grid, so navigating to Files or the keychain hid every open terminal and the strip that named them. A connection you had opened was invisible from four of the five screens. The window now has two surfaces rather than one: a nav rail that says which page you are on, and a terminal strip that is always there and switches the whole content area to a shell. Screen keeps meaning "which page" and never becomes a sixth kind of page, which is why this is two properties instead of one enum with a terminal member in it. Every screen lives inside one wrapper panel that collapses when a terminal is showing. That is not tidiness — the WebView hosts a Win32 child window that composites above everything Avalonia draws, so a screen left visible over its rectangle is a screen sliced in half, and this window has shipped that defect once already. One decision point, IsTerminalShowing, and a nested panel rather than five compound bindings nobody would remember to extend. The focus choreography is the part no test in this repo can see. Every reveal path now focuses in the same turn the WebView appeared, so all three of them post at DispatcherPriority.Loaded and let the native control re-push its bounds first. Going the other way had a real bug: the screen-changed branch called a bare Focus() where it had to release the keyboard from the native child, so switching from a terminal to Files silently ate the first keystrokes. Rare before this commit and the primary gesture after it. The tab strip grew a cross inside each tab, a plus that opens the quick-connect palette, and middle-click close. Nested buttons are correct here: Avalonia handles a left press on the cross and deliberately does not handle other buttons, which is exactly what lets middle-click bubble up from the cross as well as the tab. The test is PointerUpdateKind rather than IsMiddleButtonPressed, because the latter reports button state and is also true for a left press made while the middle button happens to be held. The handler is on the tab and not the strip, so the background closes nothing by construction. Plus opens the palette rather than a flyout, since a menu dropping into the WebView's rectangle may or may not composite above a child HWND and this repo does not make rendering claims it has not photographed. Everything a user reads now says keychain. The wire, the database and the cryptographic spec still say vault, deliberately: renaming those is a migration and a protocol change for a word. That split is written down rather than left to be rediscovered as an inconsistency. Four things that were squeezed into the keychain's category rail, or into nothing at all, now have screens. Pinned host keys get one, with fingerprints never truncated and a filter that matches them, because comparing what you have against what the operator published is the whole workflow; the approved date is read out of the item's UUIDv7 rather than added as a column, and says so, since it means first approval and not last use. Keys can be generated in the client, which needed the openssh-key-v1 container written by hand — there is no BCL or NSec helper, and the PKCS#8 route is unverified in the SSH library this uses. The armour carries no passphrase: encrypting it needs bcrypt_pbkdf, which is Blowfish with a swizzle, in a project whose crypto is otherwise entirely libsodium, for a protection the key's own remarks argue is redundant inside a vault. Generation fills the existing editor and stops, so SAVE stays the one thing that writes. ~/.ssh/config can be imported behind a preview that is ticked per row and writes nothing until the button; IdentityFile records the path and imports the key material only on an explicit opt-in, because reading somebody's private key into a vault is precisely the act this product exists to make deliberate. Match blocks and ProxyJump are reported rather than obeyed — one cannot be evaluated statically and the other has nothing behind it to route with, and a preview that implied otherwise would be worse than one that admits it. Files can be dragged in all four directions that are honestly available. Remote to Explorer does not ship and is not pretended to: the shell wants the bytes during the drop, which needs a virtual file and a native COM data object, outside what Avalonia offers. Note for the next person that Avalonia 12 replaced the drag model outright — DataObject and DataFormats are no-op stubs and IDataObject is not in the reference assembly, so every tutorial written for 11 does not compile here. Hosts can be grouped, flat and never nested. A parent id merged as a scalar lets two offline clients each re-parent A under B and B under A, producing a cycle inside an encrypted payload that no server can police and every reader would have to detect for ever. Membership lives in that payload rather than in the one plaintext concession ADR 0001 allows, whose test is that the relay cannot function without it — nothing on the server reads a group, so what plaintext would hand over is a clustering of the estate for nothing. The plaintext column reserved for it is dropped, provably always null, and the server now refuses a client that sends one; it was never populated, was copied on apply, and was not cleared on delete, so a group id would have outlived the host it described. Snippets insert through xterm rather than through the pump, because xterm is the only thing that knows whether the remote has bracketed paste on, and that is what makes a shell treat embedded newlines as text instead of as execute. The host process moves opaque bytes and never parses output, so it would have to guess, and guessing wrong runs every line. Running is off by default and the copy says the text goes into whatever is there — the terminal has no notion of being at a prompt, and may be in vi or at a password prompt with echo off, so the Enter the user presses themselves is the entire safety property. Connections and keychain changes are recorded as synced encrypted items, which is what makes them auditable by a team later and costs the server knowledge of connection rate and timing from row counts alone. ADR 0001 already concedes it cannot hide that class of metadata; the trade is now written into it rather than left implicit. A connection entry is written once, at close, which is what makes a synced log tractable: nothing to merge, one outbox row, no chance of colliding with itself. Live sessions come from memory, not from the log. The write is void by contract and posts to a bounded channel, because putting an encrypt-and-write on the teardown path of every session is how closing the application comes to take four seconds. A ticket opened before a lock still closes afterwards, since a shell outlives the vault. The activity log hooks the one generic repository every kind writes through, so it cannot miss a caller — which is also why the log kinds themselves declare they are not audited, or the first entry would write an entry about writing an entry. It records the names of the fields that changed and never their values; a log with an old password in it would be a plaintext credential store with no vault around it. Retention is 90 days or 5,000 entries, whichever bites first, pruned on the sync loop rather than on a second timer. That log traffic then broke the status line, which is worth recording because the fix is a shape and not a patch: background sync counted its own log rows as pushed items, so the quiet rule stopped being quiet and every action's message was overwritten a second later by a sync report. The report now separates log rows from user items and the rule reads the latter. S3 buckets appear as a remote in the file browser, behind the same interface an SFTP session implements, so the queue and both panes did not have to learn what they are talking to. Uploads go through a pipe, because the queue wants to write and the SDK wants to read; memory is then bounded by the part size instead of buffering a file to disk twice. Finally, the Windows device key store moved out of the session project, which was the one thing keeping it from being portable — everything else in it is platform-neutral, and a Windows CNG dependency in the middle of the vault code meant a second head could not reference it without dragging Windows along. The seam that made the move free was already there. docs/android-port.md is the audit behind that: what ports, what does not, in order of cost, the four decisions taken, and an inventory of every screen and state the interface has to carry, written so a design can be made from it directly. dotnet build, dotnet test and dotnet format --verify-no-changes are all clean: 1240 tests at zero warnings, including the end-to-end suite against real containers. The manual checks that headless Avalonia cannot make — the drag from Explorer, a generated key against a real host, twelve tabs at the minimum window width — are listed in docs/manual-checks.md and are still outstanding.
This commit is contained in:
@@ -82,6 +82,26 @@ operator all see ciphertext only. OIDC account takeover alone yields nothing rea
|
||||
complete sharing graph regardless of settings. Host addresses are plaintext when relay is
|
||||
enabled for that host; see [ADR 0004](0004-relay-authorization.md) for why that is a
|
||||
security requirement rather than a convenience.
|
||||
- **The connection and activity logs widen that leak, deliberately.** They are ordinary vault
|
||||
items — every field sealed, no plaintext column of any kind, not even a timestamp — but
|
||||
there is one row per connection and one per keychain edit, and rows have `updated_at`. So
|
||||
the operator can read a user's connection *rate and timing* off the change log without
|
||||
decrypting anything: how many machines somebody touched this morning, and at what hour they
|
||||
stopped. That is a real increase over what item counts alone gave away.
|
||||
|
||||
It is the price of the logs being auditable at all. Kept on the machine that produced them
|
||||
they cannot be read by an administrator, cannot survive a reinstall, and cannot be checked
|
||||
against anything — which makes them a diagnostic rather than an audit trail, and the point
|
||||
of them is the audit trail once shared vaults land. Retention bounds the exposure rather
|
||||
than removing it: ninety days or five thousand entries per kind, whichever bites first.
|
||||
|
||||
Two things keep it as narrow as it can be. The payload records the host's *label* and the
|
||||
address as dialled but **not** the SSH username — "who in this organisation opened a shell"
|
||||
is the audit question, and "which account they logged in as" is a detail of the host, whose
|
||||
own logs already have it. And the activity log records the **names** of the fields that
|
||||
changed and never their values — the same rule
|
||||
[ADR 0006](0006-observability-stack.md) imposes on the server's own `audit_event.detail`,
|
||||
arrived at independently on the other side of the encryption boundary.
|
||||
- **Supply chain becomes the largest practical hole.** An operator who wants the secrets
|
||||
attacks the client, not the crypto. Release signing with a key not held by the server, and
|
||||
eventually reproducible builds, matter more here than in a conventional product.
|
||||
|
||||
@@ -0,0 +1,452 @@
|
||||
# An Android client: what it would take
|
||||
|
||||
**Status: audited, scoped, not started.** No Android code exists. The four decisions that shape the work
|
||||
have been taken and are recorded in [Decisions](#decisions-taken); everything else here is the audit they
|
||||
were taken against.
|
||||
|
||||
**The shape agreed:** a **phone-first** client that is the keychain plus a **terminal**, with sessions and
|
||||
transfers protected by a **foreground service**. File transfer is not in the first scope; when it arrives it
|
||||
is **one remote pane** with Android's document picker for moving files in and out.
|
||||
|
||||
**What was actually checked**, so the rest can be read with the right amount of trust:
|
||||
|
||||
- Every project's target framework, read from `Directory.Build.props` and the `.csproj` files.
|
||||
- The target frameworks each pinned package ships, read out of the local NuGet cache — so these are the
|
||||
assemblies this solution would actually resolve, not what a package's README claims.
|
||||
- Every site in `src/` that names a Windows API, a Windows path convention, or a desktop lifetime.
|
||||
|
||||
**What was not**: nothing was compiled for Android, nothing was run on a device or emulator, and no Android
|
||||
SDK is installed here. Every statement below about *runtime* behaviour is reasoning from the code and the
|
||||
platform's documented rules, and is marked where it matters.
|
||||
|
||||
---
|
||||
|
||||
## The headline
|
||||
|
||||
The port is smaller than it looks in one dimension and much larger in another.
|
||||
|
||||
**The core is already portable.** Every project targets plain `net10.0`, with no `net10.0-windows` anywhere
|
||||
and no conditional compilation. All the Windows-specific code now sits in one project — `DodoSSH.Client.App`,
|
||||
the desktop head. The cryptography, the sync engine, the local cache, the SSH layer, the item kinds and every
|
||||
view model are platform-neutral today, and that is not luck: it is what the project structure has been
|
||||
enforcing all along.
|
||||
|
||||
(One file was out of place when this was written — `WindowsDeviceKeyStore`, in `DodoSSH.Client.Session`. It
|
||||
has since been moved, which is the only code change this audit produced; see §4.)
|
||||
|
||||
**The product is not.** DodoSSH is a two-pane file browser, a tab strip, a nav rail and a terminal, laid out
|
||||
at a minimum of 880×560, driven by hover, right-click, middle-click and drag-and-drop. A phone is about
|
||||
360dp wide and has none of those inputs. Roughly none of the *interface* ports; the question an Android
|
||||
client really asks is not "will this compile" but "what is the Android product".
|
||||
|
||||
Two platform rules make that sharper, and they are the things most likely to be underestimated:
|
||||
|
||||
- **Scoped storage.** Android has no arbitrary local filesystem for an app to browse. The left-hand pane of
|
||||
the Files screen — this machine's drives and directories — has no Android equivalent at all.
|
||||
- **Background execution.** Android stops a backgrounded process. A terminal client whose whole premise is
|
||||
that a shell survives locking the vault, and a transfer queue that runs for minutes, both assume a process
|
||||
that keeps running. On Android that needs a foreground service with a persistent notification, or the
|
||||
feature changes shape.
|
||||
|
||||
Neither is a porting problem; both were product decisions, and both have now been taken — a foreground
|
||||
service, and a single remote pane. See [Decisions](#decisions-taken).
|
||||
|
||||
---
|
||||
|
||||
## What ports as it stands
|
||||
|
||||
Verified from the resolved package assemblies.
|
||||
|
||||
| Dependency | Ships for Android | Note |
|
||||
| --- | --- | --- |
|
||||
| `libsodium` 1.0.22 | ✅ `android-arm64`, `android-arm`, `android-x64`, `android-x86` | The native half of all the cryptography |
|
||||
| `NSec.Cryptography` 26.4.0 | ⚠️ no Android-specific build | Ships `net9.0` plus iOS/tvOS/MacCatalyst. The plain `net9.0` assembly should load, since the platform-specific part is libsodium — but this is the one dependency worth proving with a build before anything else |
|
||||
| `SSH.NET` 2025.1.0 | ✅ `netstandard2.0`, `net8.0` | Sockets only; needs the `INTERNET` permission |
|
||||
| `SQLitePCLRaw.bundle_e_sqlite3` 2.1.12 | ✅ `net6.0-android31.0` | The local cache |
|
||||
| `AWSSDK.S3` 4.0 | ✅ `netstandard2.0`, `net8.0` | |
|
||||
| `CommunityToolkit.Mvvm` 8.4.2 | ✅ `netstandard2.0` | Every view model |
|
||||
| `Avalonia.Controls.WebView` 12.0.1 | ✅ `net10.0-android36.0` | The surprise — see below |
|
||||
| `Avalonia.Desktop` 12.1.1 | ❌ `net10.0` only | Replaced by `Avalonia.Android`, not ported |
|
||||
|
||||
So: **`DodoSSH.Client.Domain`, `.Storage`, `.Sync`, `.Api`, `.Auth`, `.Ssh`, `.Terminal`, `.Transfer`,
|
||||
`.ObjectStore`, `.Import` and `.Crypto` should all target `net10.0-android` unchanged.** That is the great
|
||||
majority of the code, including all of the cryptography and all of the sync protocol.
|
||||
|
||||
`DodoSSH.Client.Session` needed one file moved and no longer does — see §4. `DodoSSH.Client.App` is the
|
||||
desktop head and does not port; an Android head would be a sibling project sharing its view models.
|
||||
|
||||
---
|
||||
|
||||
## What does not port, in order of how much it costs
|
||||
|
||||
### 1. The interface — the largest item by far, and it is not a port
|
||||
|
||||
880×560 minimum, a 54-pixel nav rail, a 268-pixel host sidebar, a two-pane file browser with six columns per
|
||||
pane, a tab strip, and a layout suite (`DodoSSH.Client.App.Layout.Tests`, 64 tests) whose entire premise is
|
||||
that everything fits at that minimum.
|
||||
|
||||
None of it survives a phone. What an Android client would be is a different product with the same core:
|
||||
probably a host list, a terminal, and a single-pane file browser, with the keychain, snippets, logs and pins
|
||||
as screens rather than as a rail. The desktop screens are not a starting point for that — they are a
|
||||
different answer to a different question.
|
||||
|
||||
**This is where the real effort is**, and it is design effort before it is engineering effort. Everything
|
||||
else on this list is a week or two of work; this is the product.
|
||||
|
||||
**Decided: phone first.** See [Decisions](#phone-first) — which means a redesign rather than a reflow, and
|
||||
rules out the cheaper tablet route deliberately.
|
||||
|
||||
### 2. The Files screen's left pane has no Android equivalent
|
||||
|
||||
Scoped storage means an app sees its own directory and whatever the user hands it through the system
|
||||
picker. There is no browsable `C:\` or `/home`. So the two-pane layout — the thing the whole screen is built
|
||||
around — does not exist on Android.
|
||||
|
||||
The honest shapes are: a one-pane remote browser with **download to** and **upload from** going through the
|
||||
system document picker, or a remote-to-remote transfer tool with no local side at all. Both are fine; both
|
||||
mean the transfer queue's local half (`LocalDirectory`, the drive list, the breadcrumb trail) is desktop-only
|
||||
code.
|
||||
|
||||
Note what *does* carry: `FileTransferQueue` itself, and `IRemoteFileStore` — Phase 6 already proved that
|
||||
seam holds two very different remotes, and a `Uri`-backed Android document would be a third.
|
||||
|
||||
**Decided: one remote pane and the document picker**, and out of the first scope. See
|
||||
[Decisions](#file-transfer-when-it-comes-one-pane-and-the-document-picker).
|
||||
|
||||
### 3. Background execution
|
||||
|
||||
`TerminalWorkspace` keeps shells running across a vault lock, deliberately and documented. `FileTransferQueue`
|
||||
runs one transfer at a time for as long as it takes. `VaultViewModel` runs an auto-sync pass every minute.
|
||||
All three assume a process Android will stop.
|
||||
|
||||
The options are a foreground service with a notification for as long as a session or a transfer is live
|
||||
(which is what every serious SSH client on Android does), or accepting that backgrounding the app drops the
|
||||
connection. The first is not hard; it is a decision about what the app is allowed to do to the user's
|
||||
battery and notification shade, and it wants taking deliberately.
|
||||
|
||||
**Decided: a foreground service** while a shell or a transfer is live. See
|
||||
[Decisions](#sessions-survive-backgrounding-via-a-foreground-service).
|
||||
|
||||
### 4. The device key store — the cheap one, because the seam exists
|
||||
|
||||
`WindowsDeviceKeyStore` is DPAPI over a TPM-held key. `IDeviceKeyStore` is already the interface everything
|
||||
else uses, with three methods and an `IsAvailableAsync` that exists precisely so a platform without a
|
||||
keystore can say no.
|
||||
|
||||
Android's equivalent is the Android Keystore, with StrongBox where the hardware has it, and it is a closer
|
||||
match than the Windows one: it can require biometric or device-credential authentication to release the key,
|
||||
which is what the unlock screen would want anyway. **This is a straightforward implementation of an existing
|
||||
interface**, and it is the piece of Android integration most clearly worth doing well.
|
||||
|
||||
**Done, ahead of any decision:** `WindowsDeviceKeyStore` used to sit in `DodoSSH.Client.Session`, which was
|
||||
the one thing keeping that project from being portable. It now lives in `DodoSSH.Client.App/Platform/`, and
|
||||
its factory is `DesktopDeviceKeyStores` — named for the head it belongs to. `IDeviceKeyStore` and
|
||||
`UnavailableDeviceKeyStore` stayed behind, because they are the seam rather than an implementation.
|
||||
|
||||
The move cost nothing but a namespace, which is the useful part of the finding: the session layer takes a
|
||||
store and has never known which one, so an Android implementation drops into the same hole. Verified by the
|
||||
build and the suite, with the two Windows-only tests moving to `DodoSSH.Client.App.Tests` alongside it.
|
||||
|
||||
### 5. Sign-in
|
||||
|
||||
`BrowserLauncher` uses `Process.Start(UseShellExecute: true)`; `LoopbackCallbackListener` implements RFC 8252
|
||||
§7.3 loopback redirect with a raw `TcpListener`.
|
||||
|
||||
Neither is right on Android. `Process.Start` does not exist; the platform way is an `Intent`, and the
|
||||
platform way to receive the redirect is a Custom Tab plus an app link or a custom scheme. Loopback redirect
|
||||
*might* work, and should not be used: on a shared device any other app can bind a loopback port, which is
|
||||
exactly the attack RFC 8252 §8.3 warns about and the reason app links exist.
|
||||
|
||||
So this is a second implementation of an existing shape rather than a port. The PKCE flow, the discovery, the
|
||||
key binding and the token handling above it are all unchanged.
|
||||
|
||||
### 6. `ClientPaths`
|
||||
|
||||
Branches Windows / macOS / XDG, with an explicit comment about wanting a *local, non-roaming* directory
|
||||
because two machines sharing one cache file corrupts the outbox. On Android the right answer is the app's own
|
||||
`filesDir`, which is per-app, non-roaming and not user-visible — it satisfies the requirement more cleanly
|
||||
than any desktop platform does. One more branch, or better, the value injected by the head. `ClientPaths`
|
||||
already takes an explicit directory for exactly this reason.
|
||||
|
||||
### 7. `Environment.MachineName`
|
||||
|
||||
Used as the device name on connection and activity log entries, and when registering a device. On Android it
|
||||
returns something like `localhost`, which would make every log entry from a phone indistinguishable. Needs a
|
||||
real device name from the head.
|
||||
|
||||
### 8. The Windows-only bits of the desktop head
|
||||
|
||||
Listed for completeness; none of these is ported, they are simply absent from an Android head.
|
||||
|
||||
- `NativeKeyboardFocus` — `user32.dll SetFocus`, and the whole documented asymmetry about focus not
|
||||
returning from the WebView. Android's focus model is different and this problem may simply not exist there.
|
||||
- `Program.Main` — `[STAThread]` (required by WebView2 specifically) and `StartWithClassicDesktopLifetime`.
|
||||
An Android head is an `AvaloniaMainActivity` instead.
|
||||
- Middle-click tab close, right-click, hover states, drag-and-drop between panes.
|
||||
|
||||
### 9. The terminal — better news than expected, with one unknown
|
||||
|
||||
`Avalonia.Controls.WebView` ships a `net10.0-android36.0` target, which was the single fact most likely to
|
||||
sink this. And the transport underneath is more portable than it looks: `TerminalDataPlane` serves the page
|
||||
and the binary protocol over a **loopback WebSocket**, and an Android WebView can load `http://127.0.0.1:port`
|
||||
just as WebView2 does. The xterm.js bundles are embedded resources and are platform-neutral.
|
||||
|
||||
**Unverified, and it is the thing to check first if this goes ahead:** whether Avalonia's Android WebView
|
||||
composites the same way — a native view above everything Avalonia draws. If it does, the occlusion rule in
|
||||
`docs/platform-flags.md` applies unchanged and `IsTerminalShowing` keeps doing its job. If it does not, the
|
||||
rule is unnecessary rather than wrong, which is the harmless direction.
|
||||
|
||||
The parts that are definitely different are the on-screen keyboard, and the fact that a terminal on a phone
|
||||
needs Ctrl, Esc, Tab and arrows that the software keyboard does not offer — every Android SSH client ships an
|
||||
accessory key row for this. That is UI work, not porting.
|
||||
|
||||
---
|
||||
|
||||
## Decisions taken
|
||||
|
||||
Four, each recorded with the reasoning that was actually weighed rather than only the outcome.
|
||||
|
||||
### Scope: the keychain and a terminal
|
||||
|
||||
Not a companion, and not the file browser. Everything that is already a list or a form — hosts, groups,
|
||||
keys, passwords, snippets, pins, logs — plus opening a shell.
|
||||
|
||||
The terminal is the expensive half and it is the half that makes it an SSH client rather than a viewer. It
|
||||
depends on the WebView spike coming back clean; if it does not, the companion subset is what is left and is
|
||||
still worth shipping, so the work is ordered to find that out early.
|
||||
|
||||
### File transfer, when it comes: one pane and the document picker
|
||||
|
||||
Out of the first scope, decided now so the seams are not built the wrong way. A single remote pane, with
|
||||
Android's document picker for moving files in and out.
|
||||
|
||||
This is the shape scoped storage allows, and the interesting part is how little it costs: `FileTransferQueue`
|
||||
and `IRemoteFileStore` both carry over unchanged. Phase 6 already put a bucket behind that interface beside
|
||||
an SFTP host, so a picker-granted document is a third implementation of a seam that has been exercised twice.
|
||||
What is desktop-only is the *left* pane — `LocalDirectory`, the drive list, the breadcrumb trail.
|
||||
|
||||
### Sessions survive backgrounding, via a foreground service
|
||||
|
||||
A persistent notification for as long as a shell or a transfer is live.
|
||||
|
||||
It costs the user a notification and some battery. It buys the behaviour the desktop client already promises
|
||||
and documents — that a shell outlives a vault lock, and that a transfer finishes — and the alternative was
|
||||
to make `TerminalWorkspace`'s guarantee desktop-only, which is a worse thing to have to write down than a
|
||||
notification is to look at.
|
||||
|
||||
### Phone first
|
||||
|
||||
About 360dp wide. The tablet route was cheaper — a landscape tablet is close to the existing 880×560 minimum
|
||||
and much of the current layout could have been reused — and the phone is the device people have with them,
|
||||
which for an SSH client is most of the point.
|
||||
|
||||
So the interface is a redesign rather than a reflow, and that is the largest single item of work here. The
|
||||
nav rail, the 268-pixel sidebar and the two-pane browser do not survive. What does survive is everything
|
||||
behind them: every view model, every command, every piece of state.
|
||||
|
||||
---
|
||||
|
||||
## What the interface actually has to carry
|
||||
|
||||
Written for designing the phone client. It is an inventory of what exists today and what each part is
|
||||
*for* — not a layout, and not a claim that any of it should look the same.
|
||||
|
||||
**Read it as a checklist of things that need somewhere to go.** The desktop has room to put a warning, a
|
||||
confirmation and a form on screen at once; a phone does not, and the states most easily lost are the ones
|
||||
that appear rarely and matter most. Those are marked **◆**.
|
||||
|
||||
### Getting in: six states before the app is usable
|
||||
|
||||
`ShellState`, and every one of them is a screen.
|
||||
|
||||
1. **Starting** — reading the local cache to find out whether this machine is enrolled.
|
||||
2. **Needs a server** — nothing cached: name a server, sign in through the browser. The only state that
|
||||
requires a network.
|
||||
3. **Needs enrollment** — signed in, but the account has no vault key yet. Choose a passphrase.
|
||||
4. **◆ Showing the recovery code** — *the user must not be able to click past this.* It is the only moment
|
||||
the code exists; losing it along with the passphrase means the vault is unrecoverable, and there is no
|
||||
server-side reset by design. On desktop it is a whole screen with a confirmation. It needs to stay one.
|
||||
5. **Locked** — the unlock screen. Passphrase box, optional device unlock (biometric on Android), a status
|
||||
line, and the line saying this works with no network. **◆** Also carries two disclosures: how many shells
|
||||
are still connected behind the lock screen, and the paragraph explaining that *locked* describes the
|
||||
keychain and not this machine's access to the hosts. Plus **reset this machine** for a forgotten
|
||||
passphrase.
|
||||
6. **Unlocked** — everything below.
|
||||
|
||||
### Chrome that is present on every screen
|
||||
|
||||
- **Titlebar** — vault name, account name, a search affordance (Ctrl+K on desktop), and a sync dot with a
|
||||
label: synced, pending count, offline, unreachable.
|
||||
- **Status bar** — the selected terminal's live dot and address, the vault's last status sentence, the sync
|
||||
label again, and the search hint.
|
||||
- **Nav rail** — eight destinations: `HOSTS FILES KEYS PINS SNIPS LOGS TEAM PREFS`. Five characters is a
|
||||
desktop constraint, not a product one; the phone can use words.
|
||||
- **Terminal strip** — always visible, above every screen. Tabs with a close cross *inside* each tab, a `+`,
|
||||
and a sentence when there are none. This is what makes a terminal a surface the window switches to rather
|
||||
than a screen you navigate away from, and it is the single most desktop-shaped idea in the product.
|
||||
- **Quick connect** — a search palette over hosts that connects on Enter.
|
||||
|
||||
### The nine destinations
|
||||
|
||||
**1. Hosts** — the list of machines, and what is known about the selected one.
|
||||
|
||||
- *Sidebar:* filter box; group headings with a chevron and a count, **shown only when groups exist**; host
|
||||
rows carrying a connected dot, name, sync badge, address and one word for how it authenticates.
|
||||
- *Editor* (doubles as "add"): name, hostname, port, username, notes, one authentication picker covering
|
||||
typed password / key / stored credential, a group picker, a relay checkbox with the sentence explaining
|
||||
that relay puts the address on the server in plain text, and **◆ forget host key** — the only way back from
|
||||
a legitimately rebuilt server.
|
||||
- *Actions:* new / edit / delete, **replaced in place** by the delete confirmation rather than stacked under
|
||||
it.
|
||||
- *Right column:* the connect banner — a password box only for a host that asks for one, a sentence in its
|
||||
place when it does not, and CONNECT.
|
||||
- **◆ Unknown host key prompt** — fingerprint shown in full, TRUST AND CONNECT / CANCEL. Appears on first
|
||||
contact with any host.
|
||||
- **◆ Changed host key refusal** — deliberately has *no* continue button. Presenting this as dismissible is
|
||||
the one design mistake that matters here.
|
||||
- **◆ Conflict log** — what a merge overrode and what it discarded, scrollable, with DISMISS ALL. The merge
|
||||
is only allowed to pick a winner because this exists.
|
||||
- *Groups panel:* the groups as chips with host counts, a name box that both adds and renames, delete with
|
||||
its own confirmation counting the affected hosts.
|
||||
|
||||
**2. Files** — two panes and a queue.
|
||||
|
||||
- *Bar:* a HOST / BUCKET toggle, the matching picker, a password box for hosts that need one, CONNECT
|
||||
(or OPEN for a bucket), DISCONNECT, a connected chip, a status line.
|
||||
- *Panes:* breadcrumb trail, drive roots on the local side, and a listing with name, size, modified and —
|
||||
remote only — POSIX permissions. Each pane has an empty state and a drop highlight in two flavours,
|
||||
accepting and refusing.
|
||||
- *Queue:* direction arrow, name, the remote path, progress with bytes and rate, state, and RESUME / RETRY /
|
||||
stop per row.
|
||||
- **◆ The host key prompts appear here too.** File transfer is a second, separate connection that makes its
|
||||
own trust decision.
|
||||
- On Android this becomes one remote pane plus the document picker — see the decision above — but the queue,
|
||||
its states and the prompts are unchanged.
|
||||
|
||||
**3. Keychain** — everything that is not a host.
|
||||
|
||||
- *Categories:* ALL / SSH KEYS / PASSWORDS / BUCKETS, each with a count.
|
||||
- *Table:* name, type, one line of detail, sync badge. The detail is what is *known about* an item and never
|
||||
the secret.
|
||||
- *Four editors,* which are four different shapes: an SSH key (label, private key armour shown unmasked so a
|
||||
truncated paste is visible, passphrase, public key, notes); **generate a key** (algorithm choice, comment,
|
||||
and it fills the editor rather than saving); a password (label, username, password masked, notes); a bucket
|
||||
(label, bucket, access key id, secret access key masked, region, endpoint, **◆ a path-style checkbox with
|
||||
the sentence explaining why**, notes).
|
||||
- **◆ Delete confirmations that count** — "three hosts authenticate with this key and will refuse to connect".
|
||||
The number is the difference between a sentence somebody reads and one they click past.
|
||||
|
||||
**4. Pins** — the host keys this keychain has approved.
|
||||
|
||||
- Filter that matches **fingerprints as well as names**, because the workflow is "the operator published
|
||||
SHA256:… — do I have that one?".
|
||||
- Table: host, port, algorithm, **◆ fingerprint never truncated**, approved date.
|
||||
- Detail pane with the fingerprint in full again, a "no host uses this" chip, the note that the date is
|
||||
derived from the item id and means first approval rather than last use, and FORGET THIS HOST KEY.
|
||||
|
||||
**5. Snippets** — saved commands.
|
||||
|
||||
- Filter matching the command text as well as the name.
|
||||
- Rows: name, **◆ a "runs immediately" chip**, sync badge, and a one-line preview with newlines shown as `⏎`.
|
||||
- Editor: name, a multi-line command box, notes, and **◆ a "press Enter after inserting this" checkbox with
|
||||
the paragraph explaining that leaving it off is the whole safety property**.
|
||||
- Detail pane with the command in full and two buttons that **name the terminal they will type into** —
|
||||
`TYPE INTO prod-db` and, only for a snippet marked as running, `RUN IN prod-db`. Plus the "no terminal
|
||||
open" state, and the sentence saying whatever is in the terminal receives this.
|
||||
|
||||
**6. Logs** — two logs behind one screen.
|
||||
|
||||
- A CONNECTIONS / KEYCHAIN toggle and a refresh.
|
||||
- *Connections:* live dot, host, address, **◆ "still open" rather than a dash for a session in progress**,
|
||||
kind (terminal or files), started, device, and a chip for a refused host key.
|
||||
- *Keychain:* item, type, what happened, **the names of the fields that changed**, when.
|
||||
|
||||
**7. Preferences** — import `~/.ssh/config`, register or forget this device, sign out.
|
||||
|
||||
**8. Team** — nothing behind it, and the screen says so rather than being hidden from the rail.
|
||||
|
||||
**9. Import** — a preview before anything is written: tick per row, alias, resolved address, how it
|
||||
authenticates, a warnings chip, an "already in the keychain" badge, TICK ALL / NONE, and IMPORT N HOSTS.
|
||||
Nothing is stored until the button.
|
||||
|
||||
### States that cut across every screen
|
||||
|
||||
- **Empty states**, with copy written per screen — each says what the thing is *for*, not "no items".
|
||||
- **A read-only item**, written by a newer client: shown, refused for editing, with a message saying to
|
||||
update. Re-encoding would silently drop a colleague's field.
|
||||
- **Sync badges** per row: not synced yet, refused and waiting on a person, read-only.
|
||||
- **Unreadable items** — a count of things that would not decrypt, which is the signal that new key grants
|
||||
are needed after a rekey.
|
||||
- **Busy**, and **offline / unreachable**, which are different from each other and both different from
|
||||
"everything is synced".
|
||||
|
||||
### The five most likely to be lost on a phone
|
||||
|
||||
In the order I would worry about them, and all of them are full-width blocks today with nowhere obvious to
|
||||
go at 360dp:
|
||||
|
||||
1. The changed-host-key refusal, which must not become dismissible.
|
||||
2. The recovery code screen, which must not become skippable.
|
||||
3. The counted delete confirmations, which are the difference between a decision and a reflex.
|
||||
4. The unknown-host-key prompt, which is the one interruption that is genuinely load-bearing.
|
||||
5. The conflict log, which is what makes the merge honest rather than last-writer-wins.
|
||||
|
||||
---
|
||||
|
||||
## The order of work
|
||||
|
||||
1. ~~Decide the product questions.~~ **Done** — see [Decisions](#decisions-taken).
|
||||
2. ~~Move `WindowsDeviceKeyStore` into the desktop head.~~ **Done** — `DodoSSH.Client.Session` is now free
|
||||
of Windows APIs entirely.
|
||||
3. **The spike, and it answers two questions at once.** One throwaway Android head that unlocks a vault from
|
||||
a passphrase, then puts a WebView on the screen pointing at the terminal data plane. The first half
|
||||
settles NSec-on-Android, libsodium's native resolution, SQLite and whether the sync stack runs; the second
|
||||
settles whether the terminal is possible at all, which the scope decision now depends on. Both are cheap
|
||||
and both are gates — nothing after this is worth starting until it comes back.
|
||||
4. **Android device key store**, with biometric or device-credential release. A straightforward
|
||||
implementation of `IDeviceKeyStore`, and the piece of platform integration most clearly worth doing well:
|
||||
the Android Keystore is a closer match to what the unlock screen wants than the Windows one is.
|
||||
5. **Android sign-in**: Custom Tabs plus an app link, behind the existing seams. Not the loopback listener —
|
||||
on a shared device any app can bind a loopback port, which is the attack RFC 8252 §8.3 names.
|
||||
6. **The foreground service**, before the terminal rather than after it. A session that dies on backgrounding
|
||||
would otherwise shape every decision made while building the screen, and be expensive to unpick.
|
||||
7. **The interface**, phone-first. The actual project, and the one that dominates the estimate.
|
||||
8. **The terminal**, last — the highest-value screen, and the one whose remaining unknowns are cheapest to
|
||||
resolve once the shell around it exists. Plus an accessory key row: a software keyboard has no Ctrl, Esc,
|
||||
Tab or arrows, and every Android SSH client ships one for exactly this reason.
|
||||
|
||||
Steps 1 and 2 are done. Step 3 is a few days and retires nearly all the remaining technical risk. Steps 4–6
|
||||
are each perhaps a week and are ordinary work behind interfaces that already exist. Step 7 dominates
|
||||
everything else put together, and step 8 is small only because step 7 came first.
|
||||
|
||||
---
|
||||
|
||||
## Still open
|
||||
|
||||
Neither of these blocks the spike, and both want answering before there is anything to release.
|
||||
|
||||
- **Which Android versions.** Less forced than it first looked: the packages *compile against* API 36 and 31
|
||||
respectively, which constrains `targetSdk` rather than `minSdk`. The floor is therefore a real choice about
|
||||
which devices are worth supporting, and it should be made deliberately rather than inherited from whatever
|
||||
restores. Worth settling before the interface work, since it decides which platform APIs are available to
|
||||
design against.
|
||||
- **How it is distributed, and what that does to the supply-chain story.** ADR 0001 says plainly that an
|
||||
operator who wants the secrets attacks the client rather than the crypto, and that release signing with a
|
||||
key **not held by the server** is what that costs. Play App Signing means Google holds the release key.
|
||||
That is not necessarily wrong — it is a different, and in some ways better-audited, trust arrangement —
|
||||
but it is a change to a documented security property of this product, and it should be reasoned about in
|
||||
an ADR rather than discovered at upload time. Sideloading a self-signed APK preserves the current story and
|
||||
costs reach.
|
||||
|
||||
## Smaller things, decided by default
|
||||
|
||||
Recorded so they are choices rather than accidents. Any of them is cheap to revisit.
|
||||
|
||||
- **`ClientPaths`** gets the app's own `filesDir`, injected by the head rather than branched for inside the
|
||||
record — which already takes an explicit directory for exactly this reason. It satisfies the
|
||||
local-and-non-roaming requirement more cleanly than any desktop platform does.
|
||||
- **The device name** on log entries comes from the head, not `Environment.MachineName`, which returns
|
||||
something like `localhost` on Android and would make every entry from a phone indistinguishable.
|
||||
- **`NativeKeyboardFocus` is not ported.** It exists for a documented Win32 asymmetry — focus crosses into
|
||||
WebView2 but does not come back — and Android's focus model is different enough that the problem should be
|
||||
confirmed to exist before anything is written to solve it.
|
||||
@@ -36,12 +36,72 @@ caller's own personal one. That removes the Teams screen entirely, and with it e
|
||||
cache has six tables, none of them settings. Nothing on the design's TERMINAL preferences panel can be
|
||||
saved, and there is no frame on the terminal data plane that would carry a change to the renderer anyway.
|
||||
|
||||
**Three things the design did not ask for and this build now has.** A key can be generated in the client
|
||||
rather than pasted in (`SshKeyGenerator`, and the `openssh-key-v1` container is written by hand — see
|
||||
`OpenSshKeyWriter` for why there was no alternative and why it is written unencrypted). Hosts can be
|
||||
imported from `~/.ssh/config` (`DodoSSH.Client.Import`; it reads no key material, and `ProxyJump` is
|
||||
recorded as intent because the SSH layer still has no jump hosts). And the file-transfer screen takes drag
|
||||
and drop in four directions — remote to Explorer is the one that does not ship, because it needs a virtual
|
||||
file the platform layer cannot supply; see `docs/manual-checks.md`.
|
||||
|
||||
**The rail has six destinations, not five.** The design gives host keys no slot at all. They were a fourth
|
||||
category on the keychain screen for a while and are now a screen of their own, `KnownHostsScreen`, because
|
||||
the other categories are things somebody creates and edits and a pin is a decision recorded at the moment
|
||||
of connecting — and because comparing an untruncated fingerprint against a published one needs a column
|
||||
layout the shared table could not give it.
|
||||
|
||||
**The product surface says "keychain" and everything under it says "vault", deliberately.** The nav rail,
|
||||
the unlock and enrollment copy, and every sentence a user reads now call the encrypted store a keychain.
|
||||
The wire does not: the route is `/api/v1/vaults/{vaultId}`, the tables are `vault` and `vault_key_grant`,
|
||||
the CLR types are `VaultViewModel` and `VaultSession`, and `docs/crypto.md` — which is normative — says
|
||||
"vault key". Renaming those would break every deployed client, need a table-rename migration, and put
|
||||
`CryptoSpec.AadResourceType.Vault = 3` inside the blast radius of a find-and-replace, where changing it
|
||||
would make every item in every vault permanently unreadable. So the split is the answer rather than a
|
||||
stage on the way to one: read "vault" in this repository as the name of the cryptographic object, and
|
||||
"keychain" as what the product calls it.
|
||||
|
||||
One thing cuts the other way and is worth knowing before planning any of this: **the wire protocol already
|
||||
reserves the slots**. `SyncEntityType` (`src/DodoSSH.Contracts/SyncEntityType.cs`) has `HostGroup = 4`,
|
||||
`Tag = 5`, `HostTag = 6`, `HostCredential = 7`, `Snippet = 8` and `PortForward = 9` — reserved, unused, and
|
||||
already covered by the AAD resource-type table. Groups, tags and snippets are new item types on an existing
|
||||
protocol rather than a protocol change.
|
||||
|
||||
Two of those slots are now taken. `HostGroup` and `Snippet` shipped as full item kinds — a table, an EF
|
||||
configuration, a server kind that refuses every plaintext field, a codec, a merge, a cipher and a repository
|
||||
— and neither needed a contract change, which is what the reservation bought. `Tag`, `HostTag`,
|
||||
`HostCredential` and `PortForward` are still reserved and still unused.
|
||||
|
||||
**A third was added for something the design never mentioned**: `ObjectStore = 13`, an S3-compatible bucket
|
||||
and the keys that reach it. It is a keychain item like any other — the endpoint and the secret access key are
|
||||
both inside the payload, and the server refuses every plaintext field including the endpoint, because for
|
||||
everybody self-hosting that is an address on their own network.
|
||||
|
||||
What made it cheap is that the transfer queue never needed anything SSH-specific: `IRemoteFileStore` was
|
||||
lifted out of `ISftpSession` with only the host key left behind, and a bucket is the same contract with a
|
||||
different implementation. Three things a bucket genuinely cannot do are refused with a reason rather than
|
||||
approximated — there are no directories (only keys with slashes in them, and a marker object for an empty
|
||||
one), no resumable upload (an object cannot be written from the middle), and no atomic rename (a copy and a
|
||||
delete). Downloads *do* resume, because a ranged GET is part of the protocol.
|
||||
|
||||
**Two members were added rather than claimed**: `ConnectionLogEntry = 11` and `ActivityLogEntry = 12`, the
|
||||
first additions to `SyncEntityType` since it was frozen. Logs are synced items rather than local files
|
||||
because they are audit records — an administrator has to be able to read a shared vault's history once teams
|
||||
land, and a log kept only on the machine that produced it can be neither read nor trusted by anybody else.
|
||||
ADR 0001 records what that costs in metadata; it is not free and it is not hidden.
|
||||
|
||||
Three properties are worth knowing before touching them. An entry is **written once, at close** and never
|
||||
updated, which is what lets a synced log avoid a merge entirely. Neither kind is **audited**, which is the
|
||||
guard that stops the activity log producing an entry for every entry it writes. And both are **excluded from
|
||||
the pending-change count and from what a background sync announces** — those numbers answer "how much of my
|
||||
work is not yet safe", and a log entry is not somebody's work.
|
||||
|
||||
**One plaintext field was taken away rather than used.** `SyncPlaintextFields.GroupId` has existed since the
|
||||
contract was frozen and `host.group_id` since the first migration; no client ever wrote either. Group
|
||||
membership is inside the encrypted payload instead, the column is dropped, and the server now refuses the
|
||||
field with a reason — because what it would have handed the operator is a clustering of every user's estate,
|
||||
and ADR 0004's test for a plaintext concession is that the server *cannot function* without it. The wire
|
||||
field cannot be removed and stays as a permanently refused member; `SyncEndpointTests` holds the refusal.
|
||||
|
||||
---
|
||||
|
||||
## Chrome — titlebar, nav rail, status bar
|
||||
@@ -71,13 +131,13 @@ caption buttons and window title drawn on top of the application's own — two s
|
||||
| Design element | Layer | What it would take | What ships instead |
|
||||
| --- | --- | --- | --- |
|
||||
| Tag chips (`nginx`, `eu`, `pg16`) | client-domain | A tag item type and a host-tag join. Both reserved on the wire (`Tag = 5`, `HostTag = 6`), neither implemented, plus a payload schema bump on `HostSecret`. | Omitted. The filter box searches name, address and notes instead. |
|
||||
| Groups `PRODUCTION` / `STAGING` / `PERSONAL` | client-domain | A host-group item type (`HostGroup = 4`, reserved) or a group field on `HostSecret`. | One collapsible heading, named after the vault — the only grouping a host actually has. A second appears when a second vault becomes reachable. |
|
||||
| Groups `PRODUCTION` / `STAGING` / `PERSONAL` | client-domain | A host-group item type (`HostGroup = 4`, reserved) or a group field on `HostSecret`. | **Shipped**, as both: `VaultHostGroup` is a synced item kind and `HostSecret.GroupId` names one. Flat, not nested. A keychain with no groups renders exactly as it did before — one flat list, no headings. |
|
||||
| Group badge `TEAM·PLATFORM` | server | Teams. | Omitted. |
|
||||
| Per-host status dot, three colours | client-ssh | The amber state would mean "reachable but not connected", and nothing here ever probes a host. | Two states, both real: green when a terminal is open on that host, grey when not. |
|
||||
| `· ⤷ bastion-eu` in the host subtitle | client-ssh | **Jump hosts are data-only.** `HostSecret.JumpHostIds` is a `JumpChain` that is stored, encrypted, synced and three-way merged — and nothing reads it at connect time. `SshConnectionRequest` carries one host. | Omitted. The stored chain is preserved untouched by every edit. |
|
||||
| `SPLIT ⌘D` and side-by-side panes | client-ssh + ui | The renderer stacks panes and shows one (`terminal.css`: `.pane { position:absolute; inset:0; display:none }`). Tiling needs a real pane geometry and a splitter. | Omitted. Tabs ship instead, over the same one-WebView multiplexing. |
|
||||
| `⇄ FORWARDS · 2` | client-ssh | Port forwarding. `SyncEntityType.PortForward = 9` is reserved; nothing in the SSH layer forwards anything. | Omitted. |
|
||||
| `SNIPPETS` panel, `↵` to run | client-domain | A snippet item type (`Snippet = 8`, reserved). | Omitted. |
|
||||
| `SNIPPETS` panel, `↵` to run | client-domain | A snippet item type (`Snippet = 8`, reserved). | **Shipped**, as a screen rather than a panel. `↵` is per snippet and off by default: inserting types the command at the prompt and stops, because nothing here can tell whether the terminal is at a prompt at all. |
|
||||
| Broadcast to all panes (`⌥↵`) | client-ssh | Input is routed strictly by session id in `TerminalDataPlane.Dispatch`; there is no fan-out. Needs splits first. | Omitted. |
|
||||
| Pane header `24ms` | client-ssh | Round-trip measurement. SSH.NET offers no RTT API. | Omitted. |
|
||||
| Pane header `aes256-gcm` | client-ssh | **The closest miss on this list.** `SshNetConnection` holds the `SshClient`, so `ConnectionInfo.CurrentServerEncryption` is right there — it just is not on `ISshConnection` or surfaced by `TerminalWorkspace`. | Omitted; the tab strip shows the account and endpoint actually dialled. |
|
||||
|
||||
@@ -0,0 +1,582 @@
|
||||
# Things a person still has to check
|
||||
|
||||
Automated tests cover what they can reach. This file is the rest: the checks that need a real window, a
|
||||
real network, a real remote host, or a real Explorer — and the reasons each one is out of reach.
|
||||
|
||||
Three constraints put things on this list, and they are worth knowing before adding to it:
|
||||
|
||||
- **`MainWindow` cannot be laid out by a test.** WebView2's adapter refuses the headless dispatcher's MTA
|
||||
thread — see `LayoutHarnessTests.WhyTheWindowItselfIsNeverShown`. Anything that has to be measured lives
|
||||
on a `UserControl` instead, and what is left in the window is unmeasured by construction.
|
||||
- **Headless Avalonia has no native window.** So nothing about Win32 focus, about the WebView collapsing,
|
||||
or about a drag that crosses into another application can be asserted. A headless test of any of those
|
||||
would pass and confirm the wrong belief.
|
||||
- **No network, no container, no remote host** in the ordinary suite. The SSH suites that do use one
|
||||
(`DodoSSH.Client.Ssh.Tests`, `DodoSSH.SystemTests`) need Docker and are the exception.
|
||||
|
||||
Each item says what to do, what a pass looks like, and what a failure would mean.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — the shell and the tab strip
|
||||
|
||||
### 1.1 No screen is sliced at the WebView's left edge · **the important one**
|
||||
|
||||
Open two terminals, then visit every nav rail entry in turn — HOSTS, FILES, KEYS, TEAM, PREFS.
|
||||
|
||||
**Pass:** each screen draws whole, its buttons all clickable, and the tab strip stays across the top of all
|
||||
five.
|
||||
|
||||
**Failure means:** a screen is not collapsing while the terminal shows. The terminal is a native child
|
||||
window and composites above everything Avalonia paints, so the symptom is a screen cut off at the WebView's
|
||||
left edge with the rest unreachable. This window has shipped that defect once. The single wrapper `Panel`
|
||||
bound to `IsShowingPages` in `MainWindow.axaml` is what should make it impossible.
|
||||
|
||||
### 1.2 A tab clicked from another screen takes the keyboard
|
||||
|
||||
Go to FILES with a terminal open. Click the tab. **Start typing immediately, without clicking anything
|
||||
else.**
|
||||
|
||||
**Pass:** every character reaches the shell, including the first.
|
||||
|
||||
**Failure means:** `FocusTerminalWhenLaidOut` in `MainWindow.axaml.cs` is posting too early.
|
||||
`NativeControlHost` re-pushes its bounds on the next layout pass, so focusing ahead of that pass races the
|
||||
thing the focus depends on. The symptom is losing only the first keystroke or two, which is why this has to
|
||||
be typed immediately rather than after a pause.
|
||||
|
||||
### 1.3 Leaving a terminal gives the keyboard back
|
||||
|
||||
With a terminal focused, click FILES. Type into the filter box.
|
||||
|
||||
**Pass:** the characters appear in the box.
|
||||
|
||||
**Failure means:** `ReleaseKeyboardTo` is missing on that path. **Collapsing the WebView does not release
|
||||
the keyboard** — the native child window goes on holding Win32 focus and Avalonia then sees no key events
|
||||
at all, so the screen that just appeared silently swallows everything. This was a latent bug before the
|
||||
strip rework and is now on the hot path. See `docs/platform-flags.md`.
|
||||
|
||||
### 1.4 The middle click closes tabs and only tabs
|
||||
|
||||
Middle-click a tab (closes it), the strip background to the right of the last tab (closes nothing), and the
|
||||
`+` button (closes nothing, opens nothing).
|
||||
|
||||
**Pass:** as described. Covered by `TerminalTabsTests` headlessly, so this is a confirmation that headless
|
||||
pointer input matches a real mouse rather than a first look.
|
||||
|
||||
### 1.5 Connecting from the palette while on another screen
|
||||
|
||||
Press Ctrl+K from the FILES screen and connect to a host whose key is not yet approved.
|
||||
|
||||
**Pass:** the window lands on HOSTS with the fingerprint prompt visible and answerable.
|
||||
|
||||
**Failure means:** the prompt is behind the screen that asked for it, and the connection is blocked on a
|
||||
question that cannot be reached.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Known Hosts as its own page
|
||||
|
||||
### 2.1 The fingerprint column is readable end to end
|
||||
|
||||
Connect to two or three hosts, approving each fingerprint. Go to PINS and widen the window to its minimum
|
||||
(880px), then to something ordinary.
|
||||
|
||||
**Pass:** the full `SHA256:…` is on screen at both sizes, never cut off and never ellipsised.
|
||||
|
||||
**Failure means:** the one thing this screen is for has been broken. A truncated fingerprint cannot be
|
||||
compared against a published one — it can only be glanced at, which is the habit pinning exists to replace.
|
||||
`TheHostKeysScreenFitsWithPinsAndOneSelected` measures this at the minimum width, so a failure here is a
|
||||
size the harness does not cover.
|
||||
|
||||
### 2.2 The APPROVED date is plausible
|
||||
|
||||
**Pass:** it is roughly the day you first connected to that host.
|
||||
|
||||
**Failure means:** the version 7 identifier is being read in the wrong byte order — the symptom is dates
|
||||
tens of thousands of years out, not an error. Covered by `Uuid7TimestampTests`, so this is a confirmation
|
||||
that the ids reaching the screen really are the ones this client minted. A pin restored from an older
|
||||
client or another implementation shows `—`, which is correct rather than a failure.
|
||||
|
||||
### 2.3 Forgetting a pin reaches the server
|
||||
|
||||
With two machines signed in to the same account: forget a pin on one, sync the other.
|
||||
|
||||
**Pass:** the pin is gone on both, and the second machine asks you to check the fingerprint again on the
|
||||
next connection.
|
||||
|
||||
**Failure means:** the forward from the screen's command to the vault's has lost the push. Withdrawing
|
||||
trust that stays withdrawn only locally is the failure mode that matters here — the machines still refusing
|
||||
to reach a rebuilt server are the other ones.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Generating a key
|
||||
|
||||
Most of this one *is* covered: `KeyAuthenticationTests.AKeyThisClientGenerated_AuthenticatesAgainstARealServer`
|
||||
installs a generated public line on a real OpenSSH server in a container and connects with the private half,
|
||||
for both algorithms. That is the claim that mattered, and it is automated. What is left is the interface
|
||||
around it.
|
||||
|
||||
### 2.4 COPY PUBLIC KEY actually reaches the clipboard
|
||||
|
||||
Generate a key, save it, select it, press COPY PUBLIC KEY, then paste somewhere.
|
||||
|
||||
**Pass:** one `ssh-ed25519 AAAA… comment` line.
|
||||
|
||||
**Failure means:** the clipboard closure in `App.axaml.cs` is not finding the window. No test can see this —
|
||||
the view models take a delegate precisely so they never touch a visual, which means the one real
|
||||
implementation of that delegate is exercised by nothing but a person. `CopyingAPublicKey_WithNoClipboard_SaysSo`
|
||||
covers only the branch where there is none.
|
||||
|
||||
### 2.5 RSA-4096 does not freeze the window
|
||||
|
||||
Choose RSA 4096 and press GENERATE. While it runs, drag the window and click around.
|
||||
|
||||
**Pass:** the window keeps painting and the status line says it is working.
|
||||
|
||||
**Failure means:** the `Task.Run` is not actually taking the work off the UI thread. Ed25519 is instant and
|
||||
will not show this, so it has to be tried with RSA.
|
||||
|
||||
### 2.6 The generated key works end to end, by hand
|
||||
|
||||
Generate a key, save it, copy the public line, add it to a real host's `~/.ssh/authorized_keys`, bind the
|
||||
host to the key in its editor, and connect.
|
||||
|
||||
**Pass:** it connects without a password.
|
||||
|
||||
This duplicates the container test on purpose. The container runs one image; the thing worth knowing is
|
||||
that it works against whatever you actually run.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Importing ssh_config
|
||||
|
||||
The parser has 22 cases over the shapes a real file contains, and the end-to-end path is covered by
|
||||
`ImportingAnSshConfig_ShowsItFirstAndThenStoresWhatWasTicked`. What no test can do is read *your* file.
|
||||
|
||||
### 2.7 Scan your own `~/.ssh/config` and read the preview against the file
|
||||
|
||||
Preferences → IMPORT HOSTS → SCAN. Do not press import yet.
|
||||
|
||||
**Pass:** every entry you would expect is listed, with the address and port you expect, and the warnings
|
||||
above the table account for anything missing.
|
||||
|
||||
**What to look for specifically:**
|
||||
- A `Host *` block's `User` should appear on hosts that set none, and **not** override hosts that set one.
|
||||
- Entries whose name is a pattern (`*.internal`, `bastion-?`) should be *absent* from the table and named
|
||||
in the warnings.
|
||||
- `Match` blocks should be counted in the warnings and their settings should not have leaked onto any host.
|
||||
- A `ProxyCommand` should be reported as dropped, not silently kept.
|
||||
|
||||
**Failure means:** the importer and `ssh` disagree about what your file means, which produces bookmarks
|
||||
that nearly connect. That is worse than an import that refused, so it is worth reading the table properly
|
||||
once.
|
||||
|
||||
### 2.8 Nothing is written until the button
|
||||
|
||||
Scan, then navigate away without importing.
|
||||
|
||||
**Pass:** the Hosts screen is unchanged.
|
||||
|
||||
### 2.9 Imported hosts are correct
|
||||
|
||||
Import a couple, then open one on the Hosts screen.
|
||||
|
||||
**Pass:** the address, port and username match the config, and the notes record any `IdentityFile` path and
|
||||
any `ProxyJump` — with `ProxyJump` clearly stated as not routing. Connecting should ask for a password even
|
||||
where the config named a key, because **no key material is read**; binding it to a key in the keychain is a
|
||||
separate act.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Drag and drop on the SFTP page
|
||||
|
||||
**This is the least-covered thing in the repository, and unavoidably so.** Headless Avalonia has no native
|
||||
window and cannot synthesise a platform drag, so a test that claimed to drop a file from Explorer would
|
||||
pass while confirming nothing. What is automated is the policy — `TransferQueueingTests` covers what may be
|
||||
queued, what is skipped and what is said about it — and the wiring between a real drag and that policy is
|
||||
covered by nothing at all.
|
||||
|
||||
Connect the SFTP page to a host first. All four of these should queue transfers.
|
||||
|
||||
### 2.10 Explorer → remote pane
|
||||
|
||||
Drag one file, then several, from Explorer onto the right-hand pane.
|
||||
|
||||
**Pass:** the pane outlines in accent colour while the pointer is over it, and the drop queues one transfer
|
||||
per file into the directory showing.
|
||||
|
||||
### 2.11 Local pane → remote pane
|
||||
|
||||
**Pass:** as above. This uses the same platform file format as the Explorer drag, so a failure here with
|
||||
2.10 passing points at the drag *source*, not the drop target.
|
||||
|
||||
### 2.12 Remote pane → local pane
|
||||
|
||||
**Pass:** the left pane outlines and the drop queues a download.
|
||||
|
||||
### 2.13 Local pane → Explorer
|
||||
|
||||
**Pass:** the file copies out.
|
||||
|
||||
### 2.14 The highlight clears · **the one most likely to be wrong**
|
||||
|
||||
Drag something over a pane and then out of it again without dropping.
|
||||
|
||||
**Pass:** the outline appears and then goes away.
|
||||
|
||||
**Failure means:** an overlay is participating in hit testing. It lays out identically either way — which is
|
||||
why the layout test cannot catch it — but once visible it swallows the `DragOver` events underneath it, so
|
||||
the pointer appears to leave immediately, the highlight sticks, and the drop lands nowhere. The fix is
|
||||
`IsHitTestVisible="False"` on the highlight `Border` in `TransfersScreen.axaml`.
|
||||
|
||||
### 2.15 Dropping while disconnected
|
||||
|
||||
Disconnect, then drag a file over the remote pane.
|
||||
|
||||
**Pass:** the pane outlines in red and says "Connect to a host first." Nothing is queued on drop.
|
||||
|
||||
### 2.16 A click still selects a row
|
||||
|
||||
Click rows in both panes, and drag a row a few pixels without releasing.
|
||||
|
||||
**Pass:** a click selects; a small movement does not start a drag.
|
||||
|
||||
**Failure means:** the 4-pixel threshold in `TransfersScreen.axaml.cs` is not doing its job, and selecting a
|
||||
row has become impossible.
|
||||
|
||||
### Not implemented: remote pane → Explorer
|
||||
|
||||
Dragging a *remote* file out to Explorer is deliberately absent. It needs the source to supply a virtual
|
||||
file — on Windows, `CFSTR_FILEDESCRIPTORW` plus `CFSTR_FILECONTENTS` with delayed rendering — and Avalonia's
|
||||
`IDataTransfer` marshals `DataFormat.File` only from a storage item that resolves to a real local path.
|
||||
Pre-downloading to a temp file does not help: the shell demands the bytes during the drop. The only route is
|
||||
a native COM `IDataObject` behind a platform interface, Windows-only and outside Avalonia's supported
|
||||
surface. Use the ← button, or drag the file to the local pane first.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Host groups and snippets
|
||||
|
||||
Two synced item kinds, a sidebar that now draws headings, and one new frame between the host process and the
|
||||
renderer. The data half of all of that is covered: the payloads round-trip, the server refuses the plaintext
|
||||
fields, the sidebar's grouping and the snippet policy are in `ShellFlowTests`, and both new screens are
|
||||
measured. What is left here is the part that only exists inside a WebView, plus the two-machine cases no
|
||||
single-process test can reach.
|
||||
|
||||
### 3.1 A keychain with no groups looks exactly as it did
|
||||
|
||||
Open the hosts screen without creating any group.
|
||||
|
||||
**Pass:** the sidebar list is the flat list of hosts it always was — no headings, no UNGROUPED, nothing
|
||||
saying the hosts are unfiled.
|
||||
|
||||
**Failure means:** the "invisible until used" property is gone, and every existing user gets a heading they
|
||||
did not ask for. `RebuildSidebarRows` returns early when `Groups` is empty; that early return is the feature.
|
||||
|
||||
### 3.2 Filing hosts, and folding a heading
|
||||
|
||||
Make two groups, file some hosts into each through the host editor, then click a heading.
|
||||
|
||||
**Pass:** the heading's chevron flips and its hosts disappear; the count on the heading does not change,
|
||||
because it counts what is in the group rather than what is on screen. Clicking again brings them back.
|
||||
|
||||
**Also check:** clicking a heading does not change which host is selected — the buttons at the foot of the
|
||||
sidebar go on acting on the same machine. This is asserted in a test, but the test drives the view model
|
||||
directly; what it cannot see is whether the `ListBox` writes something else back through the binding first.
|
||||
|
||||
### 3.3 Deleting a group with hosts in it
|
||||
|
||||
Select a group with hosts and press DELETE.
|
||||
|
||||
**Pass:** the question names how many hosts are filed under it and says they stay. Agreeing removes the
|
||||
group; the hosts reappear under UNGROUPED with everything else about them unchanged.
|
||||
|
||||
**Failure means:** if the hosts vanish, the delete is rewriting host payloads, which it must not — see
|
||||
`HostGroupRepository`.
|
||||
|
||||
### 3.4 A group deleted on another machine · **needs two machines**
|
||||
|
||||
Make a group on machine A, file a host into it, sync. On machine B, sync, then delete the group and sync
|
||||
again. Back on A, sync.
|
||||
|
||||
**Pass:** A shows the host under UNGROUPED. Open that host's editor: the group picker shows "(a group that is
|
||||
no longer here)" and *keeps it selected*. Change the port and save.
|
||||
|
||||
**Failure means:** if the picker opened on "No group", saving has just unfiled the host — quietly, as a side
|
||||
effect of an unrelated edit. That is the case `BuildGroupChoices` adds the placeholder for.
|
||||
|
||||
### 3.5 A grouped host stays editable on an older build · **needs two builds**
|
||||
|
||||
Only worth doing before a release that ships alongside an older client. A host filed into a group is written
|
||||
at payload schema 4; an older build must show it and refuse to edit it, rather than editing it and dropping
|
||||
the group.
|
||||
|
||||
**Pass:** the older build says the host was written by a newer version. A host with *no* group still edits
|
||||
normally there — that is what makes the version a maximum over the fields present rather than a stamp.
|
||||
|
||||
### 3.6 Inserting a snippet · **the one that cannot be tested here**
|
||||
|
||||
Open a terminal, go to SNIPS, select a snippet with `Press Enter after inserting this` **off**, and press the
|
||||
insert button.
|
||||
|
||||
**Pass:** the terminal comes forward with the command sitting at the prompt, not run. The button named the
|
||||
tab it was going to — check that it named the right one if several are open.
|
||||
|
||||
**Failure means:** if the command runs by itself, the flag byte or the JavaScript that reads it is wrong. If
|
||||
nothing appears at all, the frame reached a pane the page does not have.
|
||||
|
||||
### 3.7 A multi-line snippet does not run line by line · **the reason the opcode exists**
|
||||
|
||||
Save a snippet whose command is three lines — `echo one`, `echo two`, `echo three` — with the run flag off,
|
||||
and insert it into a **bash or zsh** session.
|
||||
|
||||
**Pass:** all three lines sit at the prompt as one pending command, and nothing runs until Enter. Modern
|
||||
shells turn bracketed paste on, xterm.js sees that in the output stream, and `term.paste` wraps the text.
|
||||
|
||||
**Failure means:** if the first two lines execute and the third waits, the text went through as plain input
|
||||
and the bracketing did not happen — which is the whole failure this frame was added to prevent.
|
||||
|
||||
**Then insert the same snippet into something with bracketed paste off** — a raw `sh`, or a session inside
|
||||
`vi`. The lines *will* run there, and that is correct and unavoidable: without the mode there is no way to
|
||||
distinguish pasted newlines from typed ones. It is why the screen says "types this into whatever is there"
|
||||
rather than "runs this command".
|
||||
|
||||
### 3.8 RUN presses Enter
|
||||
|
||||
Select a snippet with the run flag on and press RUN.
|
||||
|
||||
**Pass:** the command runs.
|
||||
|
||||
**Failure means:** if the command appears and does not run, the `\r` is going through `paste` instead of
|
||||
`input` — inside the bracketed wrapper it is literal text, so nothing executes.
|
||||
|
||||
### 3.9 Inserting into a tab whose remote has hung up
|
||||
|
||||
Open a terminal, `exit` it, leave the tab open, then insert a snippet at it.
|
||||
|
||||
**Pass:** the screen says that tab is no longer connected, and nothing is claimed to have been sent.
|
||||
|
||||
### 3.10 Both new kinds reach a second machine · **needs two machines**
|
||||
|
||||
Make a group and a snippet on A and sync; sync B.
|
||||
|
||||
**Pass:** both arrive, with their names and — for the snippet — its run flag intact. A snippet whose flag
|
||||
arrives *set* when it was saved unset is the one failure here worth stopping for.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 — Logs
|
||||
|
||||
Both logs are synced item kinds with the whole pipeline covered: payloads round-trip, the server refuses
|
||||
every plaintext field, retention is tested against a real vault, the activity hook is tested through the
|
||||
repository every kind writes through, and the recursion guard has a test of its own. What is left here is
|
||||
the part that only happens across a lock, across a process exit, or across two machines.
|
||||
|
||||
### 4.1 A connection is recorded when the tab closes, not before
|
||||
|
||||
Connect to a host, leave the tab open, and open LOGS.
|
||||
|
||||
**Pass:** the connection is at the top of CONNECTIONS with a green dot and the words **still open** — not a
|
||||
dash, and not a duration. Close the tab and press REFRESH: the same connection now has a duration.
|
||||
|
||||
**Failure means:** a dash instead of "still open" reads as a recording that failed, which is the opposite of
|
||||
what is happening. A duration before the tab closes means an entry is being written at open, which would
|
||||
also mean it gets written twice.
|
||||
|
||||
### 4.2 The duration is plausible
|
||||
|
||||
Connect, wait a measured minute or two, disconnect.
|
||||
|
||||
**Pass:** the LASTED column agrees with the clock, rounded to whole units.
|
||||
|
||||
**Failure means:** a wildly wrong number points at the two timestamps coming from different clocks — both
|
||||
should come from the workspace's own `TimeProvider`.
|
||||
|
||||
### 4.3 Closing the application records the tabs that were open · **the one most likely to be wrong**
|
||||
|
||||
Open two terminals and close the DodoSSH window without closing the tabs. Start it again, unlock, open LOGS.
|
||||
|
||||
**Pass:** both connections have entries, with durations running up to the moment you closed the window.
|
||||
|
||||
**Failure means:** they are the ordinary way a session ends, and the workspace's own close-outs happen while
|
||||
it tears sessions down — *after* the vault they would be written into has gone. `ConnectionRecorder`'s
|
||||
`DisposeAsync` closes the tickets itself, before the session is disposed, and waits up to two seconds for
|
||||
the queue. If the entries are missing, that ordering has been broken; if closing the window became slow,
|
||||
the bounded wait has.
|
||||
|
||||
### 4.4 A shell open across a lock still gets its entry
|
||||
|
||||
Connect to a host, lock the keychain from the titlebar, unlock again, then close the tab.
|
||||
|
||||
**Pass:** the connection is recorded, into the vault it was made in.
|
||||
|
||||
**Failure means:** the ticket keeps the repository it was opened against precisely so this works. A missing
|
||||
entry means it is reading the current one instead, which would also mean an entry could be filed into the
|
||||
wrong vault once shared vaults land.
|
||||
|
||||
### 4.5 A refused host key is recorded
|
||||
|
||||
Connect to a host, approve its key, then change the key on the remote (or edit the pin) so the next
|
||||
connection is refused.
|
||||
|
||||
**Pass:** an entry appears with **host key refused** beside it. This is the row the connection log most
|
||||
exists for — a changed host key is refused with no way past it, so the status line is otherwise its only
|
||||
trace.
|
||||
|
||||
### 4.6 The SFTP session is recorded separately
|
||||
|
||||
Open the files screen and connect, then disconnect.
|
||||
|
||||
**Pass:** an entry with **files** in the KIND column, separate from any terminal entry.
|
||||
|
||||
**Failure means:** if it is missing, our log disagrees with the remote's own `auth.log`, which records the
|
||||
second login. Anybody comparing the two would be right to believe the host.
|
||||
|
||||
### 4.7 The keychain log records names and never values
|
||||
|
||||
Edit a stored password: change both the password and the username. Open LOGS → KEYCHAIN.
|
||||
|
||||
**Pass:** one row saying **changed**, with `Password, Username` in the FIELDS column.
|
||||
|
||||
**Failure means:** if any part of the old or new password appears anywhere on that screen, stop — that is
|
||||
the one thing this payload must never carry, and it would now be synced to every machine in the vault.
|
||||
|
||||
### 4.8 A pin trusted at the prompt is recorded
|
||||
|
||||
Connect to a host you have never reached and approve the fingerprint.
|
||||
|
||||
**Pass:** the keychain log shows a `KnownHostKey` **created**. This write never goes through a screen, so it
|
||||
is exactly the one a hook placed in the view models would have missed.
|
||||
|
||||
### 4.9 The pending count and the status line stay honest
|
||||
|
||||
Save a host while online and watch the titlebar and the status line for a minute.
|
||||
|
||||
**Pass:** the pending count returns to zero and stays there, and the status line keeps saying what the save
|
||||
said — it does not get overwritten a moment later by a sync report.
|
||||
|
||||
**Failure means:** every user action queues a log entry a moment afterwards. If the count sticks at 1 or the
|
||||
status line flickers to "Synchronised: 1 out", the log entries have stopped being excluded from the two
|
||||
numbers that are about the user's own work.
|
||||
|
||||
### 4.10 Both logs reach a second machine · **needs two machines**
|
||||
|
||||
Connect and edit something on A, sync; then sync B and open LOGS there.
|
||||
|
||||
**Pass:** both entries are on B, with A's device name on them. This is the claim the whole decision to sync
|
||||
these rests on.
|
||||
|
||||
### 4.11 Retention actually prunes · **slow, or needs a clock**
|
||||
|
||||
Only checkable honestly by leaving a vault in use for months, or by temporarily lowering
|
||||
`LogRetention.Default` in a debug build and watching a prune remove the excess and push the tombstones.
|
||||
|
||||
**Pass:** the count comes down, and the second machine's copy comes down too at its next sync.
|
||||
|
||||
**Failure means:** these entries sync, so a prune that does not push leaves every other machine holding
|
||||
them — and this machine deleting them again on every pass.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6 — S3 as a remote in the file browser
|
||||
|
||||
The parts that are this client's own reasoning are covered: the path-to-key translation, what a bucket must
|
||||
have before it can be stored, the server's refusal of every plaintext field, and the item kind end to end.
|
||||
What is left needs a real endpoint, and a fake would only assert our reading of the protocol back at us.
|
||||
|
||||
**Get a bucket first.** MinIO in Docker is the cheapest way and exercises the harder path — path-style
|
||||
addressing, a custom endpoint, and a region that is ignored:
|
||||
|
||||
```bash
|
||||
docker run -p 9000:9000 -e MINIO_ROOT_USER=dodossh -e MINIO_ROOT_PASSWORD=dodossh-secret minio/minio server /data
|
||||
```
|
||||
|
||||
### 6.1 Adding a bucket
|
||||
|
||||
Keychain → BUCKETS → `+ BUCKET`. Endpoint `http://localhost:9000`, path-style **on**, any region.
|
||||
|
||||
**Pass:** it saves, appears in the list with the bucket and endpoint under its name, and syncs.
|
||||
|
||||
**Failure means:** if saving is refused, read the message — the validation exists so the reason names the
|
||||
field rather than arriving later as an SDK error about resolving a URI.
|
||||
|
||||
### 6.2 Path-style addressing · **the one most likely to be wrong**
|
||||
|
||||
Save the same bucket with path-style **off** and open it.
|
||||
|
||||
**Pass:** it fails, and the failure is a name-resolution error mentioning `bucket.localhost`.
|
||||
|
||||
**Why it is worth doing deliberately:** that is exactly what a user gets when they leave the checkbox at its
|
||||
default against a self-hosted service, and the message names neither buckets nor the setting. Seeing it once
|
||||
is what makes the hint under the checkbox worth its space.
|
||||
|
||||
### 6.3 Browsing
|
||||
|
||||
Files → BUCKET → pick it → OPEN.
|
||||
|
||||
**Pass:** the right pane lists the bucket root. Prefixes appear as directories in the directory colour;
|
||||
objects appear as files with sizes and dates. The PERMS column is empty — a bucket has no POSIX mode, and a
|
||||
plausible `-rw-r--r--` would be invented.
|
||||
|
||||
**Also check** that the timestamps agree with the local pane's. Both columns are UTC; if the bucket's are out
|
||||
by your machine's offset, the `DateTime.Kind` handling in `S3FileStore.Utc` has regressed.
|
||||
|
||||
### 6.4 Upload, and the pipe underneath it
|
||||
|
||||
Upload a file of a few hundred megabytes.
|
||||
|
||||
**Pass:** it completes, the object is in the bucket at the right key and the right size, and the machine's
|
||||
memory does not grow with the file. The upload streams through a pipe into a multipart upload — nothing is
|
||||
buffered to disk twice and nothing is held whole in memory.
|
||||
|
||||
**Failure means:** if it hangs at the end, the pipe's writer is not being completed on disposal. If memory
|
||||
tracks the file size, the multipart path is not being taken.
|
||||
|
||||
### 6.5 A failed upload surfaces at the write
|
||||
|
||||
Start an upload and stop MinIO halfway.
|
||||
|
||||
**Pass:** the queue row fails with a message from the service, reasonably promptly.
|
||||
|
||||
**Failure means:** if it hangs instead, the background upload is failing without completing the pipe's
|
||||
reader — and the copy is blocked on a pipe nobody is draining. That is the case `S3UploadStream` completes
|
||||
the reader *with* the exception for.
|
||||
|
||||
### 6.6 Download, and resume
|
||||
|
||||
Download a large object, stop it partway, and resume.
|
||||
|
||||
**Pass:** it resumes from where it stopped, and the finished file matches the original. This direction is the
|
||||
one where a bucket is better than SFTP — a ranged GET is part of the protocol.
|
||||
|
||||
### 6.7 Upload resume is refused, and says why
|
||||
|
||||
Start an upload, stop it partway, and press RESUME.
|
||||
|
||||
**Pass:** it fails with a message saying an object cannot be written from the middle, so an interrupted
|
||||
upload starts again rather than resuming. RETRY from the start works.
|
||||
|
||||
**Why this is not a bug:** objects are immutable. Multipart could rebuild an interrupted transfer, but only
|
||||
by persisting the upload id and every part's ETag across the interruption. Refusing is honest; silently
|
||||
starting from zero would corrupt the file.
|
||||
|
||||
### 6.8 Delete refuses a prefix with anything under it
|
||||
|
||||
Try to delete a directory in the bucket that has objects in it.
|
||||
|
||||
**Pass:** refused, saying there are still objects under it. Deleting an empty one works.
|
||||
|
||||
### 6.9 The keys never appear anywhere they should not
|
||||
|
||||
After adding and editing a bucket, open LOGS → KEYCHAIN.
|
||||
|
||||
**Pass:** the entry says `Secret access key` in the FIELDS column and nowhere on that screen does any part of
|
||||
the key itself appear.
|
||||
|
||||
### 6.10 Against real AWS · **needs an account**
|
||||
|
||||
Repeat 6.1 and 6.3 with the endpoint blank, a real region, and path-style **off**.
|
||||
|
||||
**Pass:** it lists. This is the path that exercises `RegionEndpoint.GetBySystemName` and virtual-host
|
||||
addressing, neither of which MinIO covers.
|
||||
+22
-3
@@ -114,9 +114,11 @@ off-screen page. Worth revisiting if idle power ever matters.
|
||||
rather than refusing, so any path that fits a terminal with almost no viewport sends `window-change` for a
|
||||
2x1 window and permanently mangles the wrapped scrollback. Reachable today by minimising, and — once splits
|
||||
land — by dragging a splitter to the edge. `terminal.js` now skips the fit below 40 px in either axis.
|
||||
Related and not yet addressed: the conflict log above the terminal is an `ItemsControl` with no
|
||||
`ScrollViewer` and no `MaxHeight` on an `Auto` row, so enough conflicts squeeze the terminal row toward
|
||||
nothing.
|
||||
Related, and now fixed: the conflict log was an `ItemsControl` with no `ScrollViewer` and no `MaxHeight` on
|
||||
an `Auto` row, so enough conflicts squeezed the row below it toward nothing. It survived that long because
|
||||
it lived in `MainWindow.axaml`, which no test can lay out. Moving it into `HostsScreen.axaml` — a
|
||||
`UserControl`, and therefore measurable — is what surfaced it; it now has both, and
|
||||
`TheHostsScreenFitsWithAConflictLogTooLongToShow` fails without them.
|
||||
|
||||
**Keyboard focus crosses into the WebView by itself and does not come back.** This is the asymmetry to
|
||||
know; the connect-focus bug that led here was only its first symptom. Measured on Windows with a harness
|
||||
@@ -241,6 +243,23 @@ MIT, committed as UMD bundles under `WebAssets/vendor` and embedded as Avalonia
|
||||
esbuild step, so a clean clone builds with the .NET SDK alone. The cost is that upgrades are a manual
|
||||
re-download; the licence and versions are recorded here so that stays visible.
|
||||
|
||||
**Bracketed paste is the renderer's to decide, and it is why snippets go through a frame.** xterm tracks
|
||||
`\e[?2004h` from the remote's own output and `Terminal.paste(text)` wraps the text in paste markers only
|
||||
when the mode is on — which is what makes a shell treat embedded newlines as text rather than as "run
|
||||
this". The host process cannot make that decision: `TerminalDataPlane` moves opaque bytes and never parses
|
||||
output, so writing a snippet straight into the pump would mean guessing, and guessing wrong executes every
|
||||
line of a multi-line command. Hence `TerminalServerOpcode.Paste`. Two consequences worth keeping:
|
||||
|
||||
- The Enter for a snippet marked as running goes through `Terminal.input('\r')`, **outside** the wrapper. A
|
||||
`\r` appended to the pasted text is bracketed with it and arrives as a literal character, so nothing runs.
|
||||
- Against a remote with bracketed paste *off* — a raw `sh`, or a session inside an editor — a multi-line
|
||||
snippet does run line by line, and nothing can prevent that. It is a property of the terminal protocol,
|
||||
not of this client, which is why the screen says "types this into whatever is there".
|
||||
|
||||
Both methods were confirmed present on the public API of the vendored `@xterm/xterm` 6.0.0 bundle before
|
||||
being written against; neither is reachable from any test in this repository, so they are in
|
||||
`docs/manual-checks.md` as checks 3.6–3.8.
|
||||
|
||||
**SSH.NET's `window-change` is verified working** as of 2025.1.0 — resolved, not a flag.
|
||||
`ShellStream.ChangeWindowSize(columns, rows, width, height)` exists and the remote genuinely
|
||||
observes it: `PtyAndResizeSpikeTests` reads `stty size` back from a real sshd after resizing, and
|
||||
|
||||
Reference in New Issue
Block a user