Public Access
jaap-jan
6728a0a597
Packaging for Windows, and the updater that only exists once something is
packaged. Velopack, win-x64, fed from the project's own forge — never from the
deployment a client signs in to, which is ADR 0011 rule 2 carried over
unchanged and is why the feed address is a constant in the code rather than a
setting. See docs/adr/0012-desktop-distribution-and-updates.md.
**Nothing is ever installed while somebody is using it.** A newer build is found
on a six-hourly pass, downloaded in the background, and then waits — for a
restart the user presses, or for the next launch they were going to do anyway.
That is a policy rather than caution: this application argues at length that
locking keeps shells running, because a lock that destroyed work would stop
being used, and a restart does not keep them. Having taught that, it owes the
user the choice at the one moment it stops being true, and the sentence saying
so counts the shells it would close.
**The version is now derived from the v* tag**, by MinVer, for everything. There
was no version before this — no property anywhere, so every assembly reported
the SDK's 1.0.0 and the API served that string as its serverVersion to every
client that asked. The tag was already the version of record for the container
image; this makes it the version of record full stop. MinVer's failure mode is
answering plausibly rather than failing, and here a wrong version is a client
that never updates, so it is guarded twice: fetch-depth 0 on every checkout, and
a step that fails a tag build when the tag and the computed version disagree.
**The pack id is DodoSSH.Desktop and not DodoSSH**, which is the one decision
here that would have destroyed data. Velopack installs to %LOCALAPPDATA%\<packId>
and removes that whole directory on uninstall, and %LOCALAPPDATA%\DodoSSH is
where ClientPaths keeps the encrypted cache, the outbox of changes not yet
pushed, and the device key. The obvious id would have had the uninstaller
silently delete work the server has never seen — the thing the application
refuses to do without a counted confirmation. Velopack's own advice to move user
data to roaming %APPDATA% is declined for the reason ClientPaths already gives.
**Releases are cut by a person, and CI gains no job that could.** The tempting
argument is that a forge write token is not a signing key. It does not survive
contact with what the token does: Velopack clients trust their feed and do not
verify a package signature when they apply one, so whoever can write a release
can ship an update every install runs. That is the capability ADR 0011 rule 1
puts on a machine which is not a runner, reached through a different door. The
mechanical objection — vpk needs Windows and the runners are Linux — is the
smaller of the two and is recorded beside it, because somebody will fix one and
believe they are done.
Unsigned for now, deliberately and with the cost stated where a user reads it:
SmartScreen warns once per person, on Setup.exe, because Mark-of-the-Web is
applied by the browser that downloaded it. In-app updates are fetched by the
application and applied from a local file, and never trip it.
The banner is a fourth row of the window rather than an overlay. Anything drawn
in the terminal's rectangle is sliced by the native child window that composites
above it — the defect this window has shipped once — and a sibling row is the
arrangement TitleBar and StatusBar already prove works.
----
Three defects surfaced on the way, none of them in the feature being built.
**A settings key absent from the file came back as the CLR default, not the
declared one.** The JSON source generator builds a record through a synthesised
parameterised constructor and assigns every property from its argument array, so
a property initializer runs and is then overwritten by a default for anything the
file did not contain. A settings.json of {} read back a font size of 0, clamped
up to the 8px floor rather than the 13px the renderer draws at. It could not bite
while there was one setting, because that setting was written on every save and
so was never absent; adding a second would have turned automatic update checks
off for every existing profile, silently, the opposite of the documented default.
Reflection-based deserialisation of the same JSON answers correctly, which is why
every way of checking it by hand agrees except the one that ships. The defaults
now live on the constructor parameters, which is the only place the generator
reads them from.
**Declaring a RuntimeIdentifier on the desktop head broke the server's image
build.** It is the obvious way to let a self-contained publish restore under
locked mode, and it writes a net10.0/win-x64 target into the lock file of every
project the head references transitively — including DodoSSH.Contracts and
DodoSSH.Crypto, which the API builds too. The Dockerfile restores those with no
RID and fails NU1004. Found by running docker build rather than by reading. The
RID stays out of the committed state; the two commands that need one ask for it
unlocked, and the release script puts the lock files back.
**A Docker ARG named VERSION silently sets MSBuild's Version.** An ARG is an
environment variable for the rest of the stage, MSBuild reads environment
variables as properties, and property names are case-insensitive. With the
workflow passing main-<short sha> on a main build the publish died with
NETSDK1018 pointing at DodoSSH.Contracts, a project nobody had touched. The build
stage's argument is ASSEMBLY_VERSION now, empty except on a tag build.
All three are in docs/platform-flags.md, which is where the next person will look.
----
Verified: the whole solution builds and restores locked; 289 shell, 93 layout and
54 session tests pass, including the regression test for the settings defect and
a measurement of the banner at the window's minimum width. vpk pack runs end to
end and reports "Verified VelopackApp.Run()" against Program.Main. The API image
builds correctly both as a main build and as a tag build, carrying 1.0.0 and
0.1.0 respectively.
Not verified, and it needs a published release to be: installing, updating and
uninstalling on a real machine. That is Phase 15 of docs/manual-checks.md, and
the pack id and the WebView2 profile fix are reasoned and commented but only
proved by walking it. Two things to watch at the first upload — the reverse
proxy's body-size limit for a 64 MB asset, and whether vpk upload gitea is happy
with Gitea 1.27.1.
247 lines
16 KiB
Markdown
247 lines
16 KiB
Markdown
# ADR 0012 — Distributing the desktop client, and letting it replace itself
|
|
|
|
- Status: accepted
|
|
- Date: 2026-08-04
|
|
- Builds on: [ADR 0001](0001-e2ee-trust-model.md), [ADR 0011](0011-android-distribution.md)
|
|
- Settles: the desktop half of M4 packaging, which [ADR 0011](0011-android-distribution.md#consequences)
|
|
left open
|
|
|
|
## Context
|
|
|
|
[ADR 0011](0011-android-distribution.md) settled the phone and said explicitly what it was not settling:
|
|
"M4's desktop packaging inherits rule 2 and not the rest." This is that inheritance, plus the thing the
|
|
phone deliberately does not have.
|
|
|
|
The desktop head was not packaged at all. There were no tags, no `Version` property anywhere in the
|
|
repository, and therefore no version: every assembly reported the SDK's default `1.0.0`, and the API had
|
|
been serving that string to every client that asked it for `serverVersion`. There was no installer and no
|
|
way for anybody holding a copy to learn that a newer one existed.
|
|
|
|
That is tolerable while nobody has it. It stops being tolerable at the first release, and it stops in a
|
|
particular direction: this client holds the plaintext of a team's infrastructure credentials, by
|
|
construction (ADR 0001). For software like that, "the fix shipped and the user never got it" is a security
|
|
outcome. ADR 0011 named the cost of shipping outside a store — "no discovery, no automatic update" — and
|
|
accepted it for Android because the platform left no better option. The desktop leaves a better option, and
|
|
this ADR takes it.
|
|
|
|
The new thing an updater introduces is a capability that did not exist before: **something that can replace
|
|
the binary on a user's machine, without the user choosing each build.** ADR 0001 models the party who wants
|
|
the secrets as attacking the client rather than the crypto, and ADR 0011 turns that into a question of
|
|
custody — *which parties can ship one person a build?* An updater is a second answer to that question, so
|
|
it needs the same treatment as the signing key, and it is easy to get wrong because the dangerous part does
|
|
not look like a key.
|
|
|
|
## Decision
|
|
|
|
### 1. Velopack, per-user, under `%LOCALAPPDATA%`, with no administrator prompt
|
|
|
|
`docs/platform-flags.md` had already ruled out the platform-native option, and it is worth restating
|
|
because it is the kind of decision that gets reopened: **MSIX is not deprioritised, it is impossible
|
|
here.** A packaged application runs WebView2 in an AppContainer where loopback connections are blocked
|
|
without a `CheckNetIsolation` exemption, and the terminal data plane *is* a loopback WebSocket. MSIX would
|
|
not degrade the product, it would remove the terminal.
|
|
|
|
Velopack's path was checked against that and reintroduces nothing: `Setup.exe` is an ordinary Win32
|
|
executable that unpacks a directory and creates shortcuts, there is no package manifest and no package
|
|
identity, and the process therefore stays an ordinary desktop process. Manual check 15.4 is what would
|
|
notice if that ever changed, because it connects a real shell from the installed build.
|
|
|
|
### 2. The pack id is `DodoSSH.Desktop`, and it is irreversible
|
|
|
|
Velopack installs to `%LOCALAPPDATA%\<packId>` and **removes that entire directory on uninstall**.
|
|
`ClientPaths.DataDirectory` is `%LOCALAPPDATA%\DodoSSH`, and it holds `cache.db` with its `-wal` and `-shm`
|
|
companions, `settings.json`, and `device.key`.
|
|
|
|
So the obvious pack id would have installed the application on top of the user's encrypted cache, and
|
|
uninstalling would have deleted the device key and the outbox — the changes this machine has made and not
|
|
yet pushed, which `MainWindowViewModel.SignOutWarning` already describes to users as existing "nowhere else
|
|
in the world". The application refuses to delete that without a counted confirmation; an uninstaller would
|
|
have done it silently.
|
|
|
|
Velopack's own guidance is to keep persistent files in roaming `%APPDATA%`. **That guidance is declined**,
|
|
and `ClientPaths` already explains why: two machines writing one SQLite file through a file-sync client
|
|
corrupts it, and the outbox is per-machine by design. The install moves; the profile does not.
|
|
|
|
Like the Android package id, this is a one-way door — it is the identity an installed client matches an
|
|
update against, so changing it later orphans every existing install: still running, never updated, and
|
|
invisible to the new one.
|
|
|
|
### 3. The release is cut by a person, and the forge token never goes near CI
|
|
|
|
This is the paragraph that will be argued with, so it is the one written most carefully.
|
|
|
|
The tempting argument is that a Gitea write token is not a signing key, and so — unlike the Android
|
|
keystore ADR 0011 rule 1 keeps off runners — it could live in a CI secret and let a tag cut a release.
|
|
|
|
**It does not survive contact with what the token can do.** Velopack clients fetch from the configured
|
|
source over TLS and do not verify a package signature when they apply it. So anyone who can write a release
|
|
on this repository can publish an update that every installed client downloads and runs. That is precisely
|
|
the capability ADR 0011 rule 1 places on a machine which is not a runner, reached through a different door —
|
|
and a workflow secret is held by everyone who can change a workflow file, which for a repository with any
|
|
contributors is a wider set than it looks.
|
|
|
|
So: `scripts/release-windows.ps1`, run by a person on a Windows machine, in two phases. Phase one builds and
|
|
packs and stops. Phase two, a separate invocation, asks for the token and uploads. The split exists so that
|
|
what reaches users has been installed and started by a human first, and so that the credential is in memory
|
|
only for the minutes that need it.
|
|
|
|
There is a second, smaller reason the release could not be a CI job here anyway: `vpk` stamps and embeds
|
|
the `Setup.exe` and `Update.exe` stubs with Windows tooling, and every job in `ci.yml` is
|
|
`runs-on: [linux]`. Both reasons are recorded because somebody will fix one and believe they are done.
|
|
|
|
What CI does gain is the same thing the `android` job already does — it proves the artefact still builds.
|
|
A `win-x64` publish runs on main and on tags, so a restore graph that resolves for `net10.0` and not for
|
|
`net10.0/win-x64` fails there rather than under a person midway through a release.
|
|
|
|
### 4. The update check points at the project's forge, and the address is a constant
|
|
|
|
ADR 0011 rule 2 carries over unchanged, and its update clause carries with it: "If an update check is ever
|
|
added it points at the project's domain." Here that is `git.dodotech.cloud`, and it is a `const` in
|
|
`VelopackUpdateChannel` rather than a setting.
|
|
|
|
**The constant is the mechanism, not a convention.** A configurable feed address is exactly the knob that
|
|
would let an operator — or an edit to a plaintext `settings.json` — point the update path at the
|
|
deployment, and an operator who can answer "is there a newer version" can answer "no" forever, pinning a
|
|
chosen user to a build with a known hole while holding no key at all. Making it unsettable is that rule
|
|
expressed in a way nobody has to remember.
|
|
|
|
`ClientSettings` therefore stores whether to check, and nothing else: no address, no channel, no token. A
|
|
private release repository is incompatible with this design and that is worth knowing rather than
|
|
discovering, because the token would have to be readable before the vault is unlocked, and this file is the
|
|
one place that can be read then — which is the one place a token may not go.
|
|
|
|
### 5. `MinClientVersion` stays unread, and if it is ever read it may not fetch
|
|
|
|
`MetaResponse.MinClientVersion` has existed since M1, is served, is fetched on every sign-in, and is read
|
|
by nothing. Hanging the updater off it would have been natural and would have been wrong — and note the
|
|
shape of the error, because it is not "inherits an existing risk". Today the field controls nothing at all.
|
|
The moment an update check is conditioned on it, rule 2's sentence applies verbatim and the risk is
|
|
*created*.
|
|
|
|
The split to preserve:
|
|
|
|
- A deployment may say **"I will not serve a client this old"** and draw a remediation screen. That is the
|
|
deployment describing itself, which is legitimate and is what the field's own documentation asks for.
|
|
That screen may carry a sentence and a link to the project's release page.
|
|
- It may **not** carry a button that triggers a check or a download. A link is the user going somewhere; a
|
|
fetch is the operator's answer steering this process.
|
|
|
|
Under the design as built, an operator withholding or deflating the value achieves nothing — the check runs
|
|
on its own timer and never consults the deployment. Inflating it denies service to their own users, which
|
|
they can already do by turning the server off.
|
|
|
|
### 6. Self-contained, and not single-file
|
|
|
|
Self-contained because .NET 10 is recent enough that almost no machine has the runtime, and because the
|
|
usual objection — that runtime security patches then require an application update — is answered by the
|
|
feature this ADR is about. Velopack's deltas are per-file and the runtime files do not change between our
|
|
releases, so the runtime costs almost nothing per update; it is paid on first install.
|
|
|
|
Not single-file, for four independent reasons: `platform-flags.md` records that libsodium ships native
|
|
binaries per RID and complicates single-file publishing, and `libe_sqlite3`, `libSkiaSharp` and
|
|
`libHarfBuzzSharp` do the same; a bundle changes wholly on every build, so deltas stop working; Velopack is
|
|
a directory-based updater by design; and a self-extracting bundle puts the executable under a temp path
|
|
deep enough to hit the WebView2 long-path failure that same document records. Not trimmed — EF Core is not
|
|
trim-safe and `TreatWarningsAsErrors` turns every `IL2xxx` into a build break, so trimming is a project
|
|
rather than a flag.
|
|
|
|
**Native symbol files are excluded and ours are kept**, which is worth recording as a decision because the
|
|
numbers are so lopsided: `libSkiaSharp.pdb` and `libHarfBuzzSharp.pdb` are 100 MB of debug symbols for
|
|
third-party native code nobody here will step through, and all fifteen of our own managed PDBs together are
|
|
0.93 MB. Dropping the two took a publish from 227 MB to 127 MB. Keeping ours means an
|
|
`Exception.ToString()` carries file names and line numbers, which for a self-hosted product is the whole
|
|
diagnostic channel — the way a fault gets reported is a user pasting a stack into an issue.
|
|
|
|
### 7. One version, derived from the tag
|
|
|
|
MinVer, with `MinVerTagPrefix` of `v`, matching the tags CI already triggers on. The tag was already the
|
|
version of record for the API's container image; this makes it the version of record for everything,
|
|
including the client's own `AssemblyInformationalVersion`, which is what the preferences screen prints and
|
|
what Velopack compares.
|
|
|
|
MinVer's one sharp edge is that it answers plausibly rather than failing: a shallow clone with no tags
|
|
yields `0.0.0-alpha.0.N`. Here a wrong version is a client that never updates, so it is guarded twice —
|
|
`fetch-depth: 0` on every checkout, and a step that fails a tag build when the computed version and the tag
|
|
disagree.
|
|
|
|
The Windows application manifest's `assemblyIdentity` version is **deliberately** left at `1.0.0.0`. It is a
|
|
side-by-side activation field this application does not use and nothing reads; what a person sees comes from
|
|
the PE version resource, which MSBuild fills from `FileVersion`.
|
|
|
|
### 8. Unsigned for now, with a named trigger
|
|
|
|
Every installer will raise SmartScreen's "Windows protected your PC" until reputation accrues. The cost is
|
|
smaller and more precisely bounded than the reflex suggests, and the bound is worth knowing: Mark-of-the-Web
|
|
is applied by the *browser* that downloads `Setup.exe`, so the warning lands at first install only. In-app
|
|
updates are fetched by the application's own HTTP client and applied by `Update.exe` from a local file, and
|
|
never trip it. **One dialog per user per lifetime, not one per update.**
|
|
|
|
The trigger for buying an OV certificate on a hardware token is the first release the README invites a
|
|
stranger to install. ADR 0011 already describes Authenticode as the easy custody case — the key stays with
|
|
the developer — and the post-2023 requirement that it live on FIPS 140-2 Level 2 hardware enforces "offline,
|
|
never in CI" physically rather than by policy. `--signParams` is the single line in the release script that
|
|
changes.
|
|
|
|
**Azure Trusted Signing is not the quiet default and needs its own ADR.** It is cheaper and has no hardware
|
|
token, and it puts a compellable third party in the signing path — which is ADR 0011 rule 3's shape one
|
|
layer down, declined there for reasons that do not stop applying because the vendor changed.
|
|
|
|
## Consequences
|
|
|
|
**The desktop gets what ADR 0011 had to refuse the phone.** Discovery is still manual — somebody has to be
|
|
told where the release page is — but from the first install onward the client keeps itself current without
|
|
anybody deciding to go and look. That is the sharpest edge of the Android decision, blunted on the platform
|
|
where it could be.
|
|
|
|
**Nothing is ever installed while the application is running.** A fetched update waits for a restart the
|
|
user presses, or for the next launch they were going to do anyway. This is not caution for its own sake:
|
|
this application deliberately keeps shells running across a lock, and argues in `LockAsync` that a lock
|
|
which destroyed work would simply stop being used. A restart does end every shell, so it is a decision that
|
|
belongs to the person whose job is running in one — and the interface says so, in the same words the close
|
|
button already uses.
|
|
|
|
**The release is a manual step, and that will feel slow.** It is roughly ten minutes of a person's attention
|
|
per release, and the convenience being refused is the entire point of CI. Where the two collide the custody
|
|
argument wins, exactly as it does for the Android keystore.
|
|
|
|
**The forge grows by about 125 MB per release, forever.** Measured on the first real pack rather than
|
|
estimated: a 127 MB publish directory compresses to a 60 MB full `.nupkg` and a 64 MB `Setup.exe`, and both
|
|
are uploaded. Velopack needs the previous full package present to build a delta against, so pruning old
|
|
releases has a real cost — a client several versions behind falls back to a full download. A 64 MB asset is
|
|
also large enough to meet whatever body-size limit fronts `git.dodotech.cloud` (nginx's
|
|
`client_max_body_size` defaults to 1 MB), which is worth checking before the first upload rather than
|
|
discovering after ten minutes of transfer.
|
|
|
|
**Uninstalling leaves the vault cache behind, on purpose.** `%LOCALAPPDATA%\DodoSSH` survives, so a
|
|
reinstall finds an enrolled machine and asks for the passphrase — which is what somebody reinstalling wants.
|
|
The honest cost is that `device.key` is left too, and the account goes on listing a device that is no longer
|
|
installed. That is a wart rather than a hole: the blob is decryptable only by this machine's TPM, and Sign
|
|
Out is the button that withdraws the registration. An uninstall is not a sign-out and must not pretend to
|
|
be one.
|
|
|
|
**Contracts and client now share a version number.** `DodoSSH.Contracts` is packable, so a contracts-only
|
|
change ships as a client version bump. One number is the point; this is the price of it.
|
|
|
|
**The Android head's `versionName` now follows the same tag**, while its integer `versionCode` stays
|
|
hand-bumped, because Android needs a monotonic integer and SemVer does not provide one. Nothing else about
|
|
ADR 0011 changes.
|
|
|
|
## Rejected
|
|
|
|
- **MSIX.** Not a preference. It would break the terminal outright; see decision 1.
|
|
- **A CI job that cuts the release on a tag.** The convenience is the point of CI and the custody is the
|
|
point of ADR 0011; where they collide the custody wins. See decision 3, and note that a Windows runner
|
|
answers the mechanical objection while leaving the real one untouched.
|
|
- **A configurable update feed.** Named here because it is the change somebody will propose in good faith,
|
|
for a self-hosted product where making things configurable is usually right. It is the one setting that
|
|
would hand the operator the capability the whole trust model is about.
|
|
- **The deployment serving the installer.** Refused again, for the third ADR running, because it is
|
|
genuinely the nicest onboarding available and will be proposed again.
|
|
- **Conditioning updates on `MinClientVersion`.** See decision 5. It would create the attack rather than
|
|
inherit it.
|
|
- **Azure Trusted Signing**, for now, on custody grounds rather than on mechanics. See decision 8.
|
|
- **A hand-edited version property.** Considered seriously against MinVer, and it loses on the thing that
|
|
matters here: the tag is already the version of record for the container image, and two places to write
|
|
one number is a pair that can disagree. MinVer's silent-wrong-answer failure mode is real and is what the
|
|
two CI guards in decision 7 exist for.
|