Let the Linux head check for updates, and seal its device key in the TPM

Two things the RPM shipped without, and the reason they arrive together is
that both are the same question — what may this platform ask of the machine,
and what must it not ask of the user.

◆ UPDATES: THIS CLIENT CHECKS AND FETCHES, AND PACKAGEKIT INSTALLS.

ADR 0013 rule 11 said there was no updater at all, and that went too far. It
conflated noticing that a newer build exists with installing it: the second is
what the trust argument is about, and the first is not — a client that checks
a fixed address and tells you what it found has taken no capability from
anybody. Written as a flat refusal, the rule bought its safety by paying a cost
that was avoidable, and the ADR now says so in its own words.

So LinuxUpdateChannel reads the rolling nightly release, compares versions the
way rpm compares them, downloads the package, verifies its digest and hands the
file to PackageKit over gdbus. Polkit asks; the user may say no; nothing is
torn down before the answer, because ApplyingEndsTheProcess is false and the
shell already knows what that means — it is the phone's shape, and declining an
update must not cost somebody their open shells.

Three details that are load-bearing rather than incidental:

  - The comparison is rpmvercmp and not SemVer, because rpm is what will accept
    or refuse the install. Same argument ADR 0014 makes for versionCode. The
    installed side is read out of the rpm database rather than derived from the
    assembly, so the SemVer-to-rpm translation exists in exactly one place. All
    28 expected values in RpmVersionTests came out of rpm itself rather than out
    of a reading of the algorithm.

  - The digest is checked and is not a signature. Velopack verifies its own
    downloads and Android checks a signature; an RPM over HTTPS has neither. The
    manifest names a SHA-256 and a mismatch deletes the file rather than leaving
    something installable-by-hand in the profile directory.

  - ONLY_TRUSTED is cleared, which is what routes the request to polkit's
    package-install-untrusted action. The package is unsigned, so requiring
    trust would fail every update at the last step.

◆ THE DEVICE KEY: SEALED IN THE TPM, BEHIND A PIN THE TPM CHECKS.

ADR 0007's amendment is the bar: a gate inside the process is not a gate. The
key is sealed into a TPM 2.0 keyedhash object whose userAuth comes from a PIN,
so unsealing is a command the chip refuses; the blob is encrypted to the storage
hierarchy and is useless on any other machine; nothing here ever compares a PIN.

The sealed object deliberately carries no NoDA attribute, and that one omission
is the whole reason four digits is enough: every wrong answer advances the TPM's
dictionary-attack counter and the chip stops answering entirely once it trips.
Measured at four wrong tries against a software TPM, after which the correct PIN
gets nothing either. It is asserted by a test rather than left to a reading of
the template, because removing the attribute leaves every other assertion
passing.

This is weaker than Hello and Touch ID and the difference is invisible, so it is
written down in three places rather than smoothed over: those raise their prompt
from inside the platform and this one is a window we draw. The prompt is
deliberately plain for that reason — teaching people that a convincing DodoSSH
PIN box is a system dialog is the one thing this design must not do.

Rejected, each for failing the amendment: the Secret Service API, which has no
per-use consent and is DPAPI's shape exactly; fprintd, which answers a question
and holds nothing, so skipping the call skips the gate; and a polkit-gated root
helper, which would work and puts a privileged component in a package that
installs nothing setuid.

Availability is narrower than "has a TPM": on Fedora /dev/tpmrm0 is root:tss and
desktop users are not in tss, so the ordinary case reports unavailable and keeps
asking for the passphrase. Shipping a udev rule to widen that is refused — it is
the administrator's decision, not an application package's.

◆ WHAT IS ACTUALLY VERIFIED, SINCE THAT IS THE PART THAT USUALLY ISN'T.

This is the only device key store in the repository with real coverage, and it
is only possible because the PIN is a delegate and the TPM is a device: seal,
unseal, wrong PIN, lockout, decline and a foreign blob all run unattended
against a software TPM. Windows and macOS cannot be tested at all — their
prompts block a suite forever, which WindowsDeviceKeyStoreTests records.

TSS.Net's own TcpTpmDevice cannot reach swtpm: it opens the platform socket too
and exchanges a handshake only the Microsoft reference simulator answers, so
Connect() blocks with no error and no timeout. SoftwareTpm speaks the data
channel and nothing else.

The suite also lied once and was fixed: the lockout test trips shared state, and
without a DictionaryAttackLockReset in Dispose every later test got null from a
correct PIN — six of them assert null and passed for entirely the wrong reason.

End to end on a real Fedora 44: a genuine linux-x64 publish packages, installs,
and every DT_NEEDED in the installed tree resolves except liblttng-ust, which is
the one this spec deliberately excludes. What no runner covers is /dev/tpmrm0,
PackageKit and polkit, and Phase 19 grew five checks for exactly those.

Also fixed: the magic-bytes literal picked up raw control characters, which made
LinuxDeviceKeyStore.cs binary to git — no diffs and no line-ending normalisation.

README.md

@@ -71,7 +71,7 @@ src/
   DodoSSH.Client.ObjectStore  S3-compatible buckets, behind the same interface as SFTP
   DodoSSH.Client.Import    reading ~/.ssh/config, and the keys it names when asked
   DodoSSH.Client.Shell     the view models both heads drive, the renderer's files, the palette
-  DodoSSH.Client.App       the desktop head: its views, and its Windows integration
+  DodoSSH.Client.App       the desktop head: its views, and its Windows, macOS and Linux integration
   DodoSSH.Client.Android   the phone head: its views, and its Android integration
 tests/                     one test project per source project
 docs/adr/                  architecture decision records
@@ -81,7 +81,9 @@ docs/manual-checks.md      what no test can reach, and what to look for when che
 docs/android-port.md       the Android head: what was decided, what is built, what is left
 scripts/                   release-windows.ps1 — builds, packs and publishes the Windows client
                            release-macos.sh   — the same, signed and notarized, on a Mac
+                           ci-linux-rpm.sh    — builds the Linux .rpm, then interrogates it
 build/macos/               the entitlements and Info.plist template the macOS bundle is built from
+build/linux/               the RPM spec the Linux package is built from
 ```
 
 Everything under `src/DodoSSH.Client.*` except the two heads and `Shell` is deliberately free of Avalonia.
@@ -189,19 +191,38 @@ sudo dnf install ./dodossh-nightly-*.x86_64.rpm
 Everything above about where a client may come from applies unchanged. Four things differ, and the first
 two are the ones to read before installing.
 
-**There is no self-updater, and that is the design rather than a gap.** The Windows and macOS builds carry
-Velopack and replace themselves; this one carries nothing of the sort and never contacts an update service.
-On Linux the package manager is already an updater the person running it trusts, audits and controls, and
-adding a second one that answers somewhere else would be handing back exactly the capability
-[ADR 0013](docs/adr/0013-desktop-distribution-and-updates.md) rule 4 spends a page keeping out of reach.
-The cost is real and worth stating plainly: this project publishes no package repository, so nothing tells
-you when a newer build exists. You install the next one the way you installed this one.
+**It checks for updates and it installs nothing.** The Windows and macOS builds carry Velopack and replace
+their own files; this one never does. It checks the project's forge every six hours, and when there is a
+newer build it downloads it, checks its digest, and hands the file to **PackageKit** — which raises the
+usual "authentication is required to install software" prompt. You may say no, and nothing is replaced until
+you say yes. Nothing restarts either: replacing files under a running process is ordinary here, so the build
+you have keeps running until you close it.
 
-**Your passphrase is asked for every time, because there is no hardware key store here.** Windows has a TPM
-behind a consent dialog and a Mac has the Secure Enclave behind Touch ID; the Linux head has neither wired
-up, so the "unlock without the passphrase" path is simply not offered — the application knows it has no
-store and does not pretend otherwise. See
-[docs/unlocking-without-the-passphrase.md](docs/unlocking-without-the-passphrase.md).
+That split is the point rather than a compromise. Installing software is your package manager's job and it
+already answers to you; noticing that a build exists is the part `dnf` cannot do for a package that is not
+in a repository. What DodoSSH must never become is a second thing that can put software on your machine on
+somebody else's say-so, which is why the address it checks is a constant in the binary and can never be a
+DodoSSH server — [ADR 0013](docs/adr/0013-desktop-distribution-and-updates.md) rules 4 and 11.
+
+The gap that remains: there is **no package repository**, so `dnf upgrade` alone will never bring you a
+newer DodoSSH. If you turn the check off on PREFERENCES → UPDATES, nothing else will tell you.
+
+**Your PIN can stand in for your passphrase, if this machine has a TPM you can reach.** The device key is
+sealed into the TPM and released only against a PIN that **the TPM itself checks** — it counts wrong answers
+and stops responding after a few, which is what makes four digits enough and what makes a stolen disk
+useless. Two honest caveats, both in
+[ADR 0007](docs/adr/0007-device-key-protection.md) decision 4:
+
+- **On most Fedora installs this is not offered**, because `/dev/tpmrm0` belongs to `root:tss` and your
+  account is not in `tss`. DodoSSH will not widen that for you — granting every local user access to the
+  machine's TPM is the administrator's call. If you want it: `sudo usermod -aG tss $USER`, then log out and
+  back in.
+- **It is weaker than Windows Hello or Touch ID**, and the difference does not show. Those draw their prompt
+  from inside the operating system; this one is a window DodoSSH draws, so something already running as you
+  could imitate it. It could imitate the passphrase screen too, which is worth far more — but the guarantee
+  is not the same and this page will not pretend it is.
+
+See [docs/unlocking-without-the-passphrase.md](docs/unlocking-without-the-passphrase.md).
 
 **It needs WebKitGTK, because the terminal is a WebView.** Specifically `webkit2gtk4.1`, which `dnf` pulls
 in for you. Fedora 44 is the distribution the head has actually been run on. RHEL 9 and its rebuilds ship
@@ -969,21 +990,29 @@ keychain plus a terminal — and the spike that gates all of it.
   [ADR 0013](docs/adr/0013-desktop-distribution-and-updates.md) decision 10 and
   [Installing on macOS](#installing-on-macos).
 
-  **The Linux half is a package rather than an updater.** An `.rpm` for x86_64, built and checked on every
-  push to `main` and published to the nightly release, installing to `/opt` with a menu entry and a `dodossh`
-  launcher. It carries no self-updater at all and contacts no update service — on this platform `dnf` is
-  already an updater the user controls, and a second one answering somewhere else is the capability the
-  trust model exists to keep out of reach. It also has no hardware-backed device key store, so the
-  passphrase is asked for every unlock. See
+  **The Linux half checks, and the package manager installs.** An `.rpm` for x86_64, built and checked on
+  every push to `main` and published to the nightly release, installing to `/opt` with a menu entry and a
+  `dodossh` launcher. It carries no Velopack and replaces nothing itself: it notices a newer build on the
+  project's forge, downloads it, verifies its digest and hands the file to PackageKit, which asks before it
+  installs. Splitting it that way keeps the part that can put software on your machine where it already
+  was — with your package manager — while fixing the half `dnf` cannot do for a package that is in no
+  repository. The device key is sealed into the TPM behind a PIN **the TPM checks and counts failures
+  against**, which is what makes four digits enough; on most Fedora installs it is not offered at all,
+  because an ordinary user may not open `/dev/tpmrm0` and this package will not widen that for them. See
+  [ADR 0007](docs/adr/0007-device-key-protection.md) decision 4,
   [ADR 0013](docs/adr/0013-desktop-distribution-and-updates.md) decision 11 and
   [Installing on Linux](#installing-on-linux).
 
   Still to do here: Windows signing (the first Windows release is unsigned, and the trigger for buying a
   certificate is the first release aimed at strangers), macOS on Intel, a `v*`-tagged Linux release and a
-  package repository to serve it from, a Linux device key store, and Phases 18 and 19 of the manual
-  checks — neither the macOS nor the Linux build has been walked through by a person. There is no macOS
-  runner in CI at all, and the Linux package is verified only as far as what it *says* about itself: CI
-  builds it and interrogates its dependencies, its file list and its modes, and installs nothing.
+  signed package repository to serve it from, and Phases 18 and 19 of the manual checks — neither the macOS
+  nor the Linux build has been walked through by a person. There is no macOS runner in CI at all. The Linux
+  package is verified as far as what it *says* about itself — CI builds it and interrogates its
+  dependencies, its file list and its modes, and installs nothing — and the two pieces of Linux behaviour
+  that are code rather than packaging do have tests: the update channel's version comparison and digest
+  check run in CI, and the TPM store's seal, unseal, wrong-PIN and lockout paths run against a software TPM
+  anybody can start with one `docker run`. What no runner covers is `/dev/tpmrm0`, PackageKit and polkit,
+  which is what Phase 19 is for.
 - **M5 — multi-provider OIDC**, identity key rotation, per-item content keys.
 
 ## Licence