Merge branch 'claude/android-release'

2026-08-05 22:49:51 +02:00
parent 8591035170 af0e29a98b
commit 174ef7c420
16 changed files with 712 additions and 24 deletions
@@ -228,6 +228,56 @@ changes.
 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.

+### 9. There is a second desktop channel, published by CI, and it is a second application
+
+[ADR 0014](0014-android-updates.md) gave the phone a nightly channel and rule 3 above gives the desktop
+none, which left the two heads with different answers to the same question — *how does somebody try what
+is on main?* — for no reason other than the order the work happened in. This is the desktop's answer, and
+it is the phone's arrangement with one difference that changes how much of it has to be built.
+
+**Android gets the separation from the platform. Windows does not.** Two Android channels cannot replace
+one another because the installer refuses a package signed by a different key; a mistake there is loud.
+Velopack applies what its feed serves and verifies no signature, so on this head the separation is entirely
+construction:
+
+| | release | nightly |
+| --- | --- | --- |
+| pack id | `DodoSSH.Desktop` | `DodoSSH.Desktop.Nightly` |
+| Velopack channel | `win` | `win-nightly` |
+| feed | newest non-prerelease release | the rolling `nightly-desktop` prerelease |
+| profile | `%LOCALAPPDATA%\DodoSSH` | `%LOCALAPPDATA%\DodoSSH.Nightly` |
+| cut by | a person, from a `v*` tag | CI, on every push to main |
+
+Four separations rather than one, because each closes a different door. The pack id decides the install
+directory and what an installed client matches an update against, so it is what makes a nightly install
+*beside* rather than *over*. The channel names the index file on the feed, so neither build ever reads the
+other's — and the release channel additionally refuses prereleases, which is belt and braces in the one
+direction that matters: an unsigned CI build must never reach a machine somebody is trusting with their
+credentials. The profile is the one that is easy to skip and would hurt most: the cache schema is migrated
+on every launch, before unlock, so a shared profile means a nightly quietly upgrading a database the
+release build then opens.
+
+**The prerelease flag is also how the two heads stay out of each other's way.** The phone's release channel
+reads `releases/latest`, which skips prereleases. A desktop nightly published as a stable release would
+become the newest release in this repository, and every phone on the release channel would start failing
+its check against a release carrying no Android manifest. The nightly is published with `--pre` for its own
+sake and for that one.
+
+**What this costs, stated where somebody will read it before installing:** whoever can write a release on
+this repository can put a build on every nightly desktop, because the client applies what the feed serves
+without verifying a signature. That set includes CI and therefore everyone who can change a workflow file.
+It is the same trade [ADR 0014](0014-android-updates.md) accepted for the phone's nightly, and it is
+acceptable for the same reason and only that reason: this is not the channel anybody's real credentials are
+on. Rule 3 is untouched — the release channel still has no job, no token and no runner.
+
+**The version gets a floor, on this channel only.** MinVer answers `0.0.0-alpha.0.N` until the first `v*`
+tag and `vpk` refuses to pack anything below `0.0.1`, so the nightly job lifts the patch digit and keeps
+the prerelease height. It is applied through `MinVerVersionOverride`, which moves the assembly version too
+— packing a number the assemblies disagree with would put one version in the installer and another on the
+preferences screen, which is the screen somebody reads when asked which nightly they are running. Ordering
+across the floor holds: heights rise within a floored version, and the first real tag moves past all of
+them. The release script gets no floor and must not have one; there, `0.0.0` should be refused.
+
 ## Consequences

 **The desktop gets what ADR 0011 had to refuse the phone.** Discovery is still manual — somebody has to be
@@ -116,6 +116,15 @@ is the entire reason there are two.
 other is an uninstall and a fresh enrolment. There is no migration and there will not be one — the two
 caches are encrypted under keys held by two package identities the platform keeps apart.

+◆ **The desktop has since taken this arrangement, and it had to build what Android is given.**
+[ADR 0013](0013-desktop-distribution-and-updates.md) decision 9 is this ADR applied to Windows: a nightly
+CI publishes from main, installing beside the release build rather than over it. The difference worth
+carrying back here is that every separation this ADR gets from the platform — different package identity,
+signature-checked updates, a per-app data directory — is on Windows a thing somebody had to choose and can
+therefore undo. The paragraph above about the attack surface applies there word for word, with one line
+removed: on the desktop the packages are not signed at all, so the feed is the only thing standing between
+a nightly install and an arbitrary build.
+
 **ADR 0011's "no automatic update" consequence is now wrong for the release channel and remains true for
 reach.** Discovery, MDM deployment and the sideloading permission are all unchanged. What changed is only
 that an installed copy can now learn a newer one exists.