feat(desktop): Tauri v2 kiosk shell — maximized window, prod right-click block, auto-update + code-signing
Add apps/desktop, a thin Tauri v2 shell wrapping the SAME @parking/web SPA so the desktop and browser UIs never drift: dev loads the Vite dev server (HMR), prod bundles the web app's dist/. No business logic in the shell (device/auth/ ledger stay in @parking/server); deny-by-default capabilities. apps/web (single UI source of truth): - lib/origin.ts: centralize the backend origin (API_BASE/apiUrl/wsUrl from VITE_API_BASE); no-op in the browser, lets the desktop build target Fastify. - lib/kiosk.ts: block the right-click context menu in PROD only (dev keeps it + devtools). - lib/desktop-updater.ts: prompt-on-update auto-update (no-op in browser/offline) → downloadAndInstall + relaunch; i18n update.* keys (sq+en). - .env.production: VITE_API_BASE wired to the Fastify origin for the bundle. Desktop: - window starts maximized (not fullscreen — operator keeps OS access). - auto-update via tauri-plugin-updater + -process; self-hosted endpoint is a PLACEHOLDER to fill in. Updater keypair: pubkey embedded in tauri.conf.json; private key + password kept OUTSIDE the repo (~/.parking-updater-keys) and as TAURI_SIGNING_* build secrets. - Turbo build is a no-op; the real signed bundle is `pnpm --filter @parking/desktop bundle` (verified → .deb/.rpm/.AppImage + .sig signatures). Verified: cargo check clean; turbo run build lint 14/14 green; i18n parity holds; no key/sig/bundle artifacts in the repo. Wiki (security + desktop analysis recorded alongside): - new concepts/tpm.md (TPM 2.0: how it works, sealed-LUKS auto-unlock + non- extractable signing key, limits — live-root, bus-sniff — TPM-vs-ATECC608 by platform). - new decisions/desktop-shell-tauri.md (Tauri v2 over Electron; best-case Ubuntu 26.04 LTS, worst-case Windows+WSL → kiosk browser; full as-built). - pull-the-disk attack trace on append-only-event-chain; ATECC608 not-in-a-PC caveat; cross-links from disk-os-hardening / threat-model. - open-questions #11 (appliance WebKitGTK), #12 (TPM hardening impl), #13 (startup verifyChain self-check); index/overview/log/standing-decisions. Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
This commit is contained in:
@@ -69,10 +69,21 @@ secure element is a new `Signer` impl with no `EventLog` change; each event stor
|
||||
so old events stay verifiable.
|
||||
|
||||
> ⚠️ The software signer makes the chain **self-consistent + tamper-evident**, but **not
|
||||
> unforgeable by someone who owns the host** — only the ATECC608's non-extractable key gives
|
||||
> property (3) above. Until the chip is wired, the chain detects tampering by *outsiders* and
|
||||
> *accidental* corruption, but an operator with the signing key + DB access could re-sign a
|
||||
> forged chain. This is the central reason #6 matters.
|
||||
> unforgeable by someone who owns the host** — only a non-extractable key in a secure element
|
||||
> ([[atecc608]] on embedded, or the host **[[tpm|TPM]]** on a PC appliance) gives property (3) above.
|
||||
> Until that is wired, the chain detects tampering by *outsiders* and *accidental* corruption, but an
|
||||
> operator (or anyone who pulls the SSD and reads the `.env`) has the HMAC key and could **edit a row
|
||||
> and re-sign the whole chain undetectably**. This is the central reason #6 matters.
|
||||
|
||||
> **Pull-the-disk attack (traced 2026-06-21).** Removing the SSD, editing `parking.sqlite` on
|
||||
> another machine, and rebooting: any blind edit/delete/reorder **breaks the chain** and
|
||||
> `verifyChain()` pinpoints it (bad signature / index gap / prevHash mismatch / unknown keyId). **But
|
||||
> two gaps:** (a) **nothing runs `verifyChain()` at startup today** — the tamper is *detectable but
|
||||
> undetected* until something invokes verification (wire a boot-time self-check that at least logs/flags
|
||||
> a signed alarm — fail-open on exit still governs; this is [[open-questions]] #13); and (b) with the
|
||||
> *software* signer the key is on the same disk, so the attacker can re-sign and pass verification —
|
||||
> only a secure-element key ([[tpm]]/[[atecc608]]) closes that. [[tpm|TPM-sealed]] LUKS additionally
|
||||
> stops the disk **mounting** off-host at all.
|
||||
|
||||
### Business-layer event types (the ledger)
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
type: concept
|
||||
tags: [parking, security, platform]
|
||||
sources: [parking-system-architecture]
|
||||
updated: 2026-06-14
|
||||
updated: 2026-06-21
|
||||
---
|
||||
|
||||
# Disk / OS Hardening
|
||||
@@ -18,6 +18,12 @@ Physical-access attacks on Windows are trivial (boot media + password-reset tool
|
||||
- **GRUB password + Secure Boot** — prevents boot-parameter tampering / unsigned loaders.
|
||||
- **No desktop environment** — single-purpose appliance.
|
||||
- **Key-based SSH only.**
|
||||
- **[[tpm|TPM 2.0]]** _(recommended, 2026-06-21)_ — seals the LUKS key to the boot chain so the disk
|
||||
**auto-unlocks only on an untampered boot**, making encryption-at-rest compatible with **unattended
|
||||
reboot** (a booth must come back up after a power cut without a human typing a passphrase). Also a
|
||||
candidate home for the non-extractable host event-signing key. Caveats (live-root limit, bus-sniff,
|
||||
PCR brittleness, mandatory recovery passphrase + re-seal runbook) on [[tpm]]; implementation is
|
||||
[[open-questions]] #12.
|
||||
|
||||
With LUKS in place, **SQLCipher becomes optional** defence-in-depth rather than the critical
|
||||
layer. (The custom controller adds its own: ESP32 flash encryption + secure boot — see
|
||||
|
||||
@@ -13,8 +13,8 @@ The **second foundational force** (with [[offline-first]]). The central insight
|
||||
## The key reframing
|
||||
|
||||
Early thinking focused on protecting the database **at rest** — SQLCipher, LUKS, BitLocker,
|
||||
TPM-sealed keys. All of that defends against **an outsider who steals the machine or boots from
|
||||
external media**.
|
||||
[[tpm|TPM-sealed keys]]. All of that defends against **an outsider who steals the machine or boots
|
||||
from external media**.
|
||||
|
||||
That is the **wrong primary threat**. The most likely adversary is the **legitimate operator at
|
||||
the booth**. While the app runs, the database is decrypted in memory and the operator has full
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
type: concept
|
||||
tags: [parking, security, platform, hardware]
|
||||
sources: []
|
||||
updated: 2026-06-21
|
||||
---
|
||||
|
||||
# TPM 2.0 (Trusted Platform Module)
|
||||
|
||||
A small crypto chip on the host that provides two host-hardening primitives. Useful **defence-in-
|
||||
depth** for the appliance, but — like all secure elements — it defends the **secondary**
|
||||
([[threat-model|outsider-with-the-box]]) threat, **never** the operator-at-the-booth, and is **not**
|
||||
a substitute for the system's real anti-fraud control ([[reconciliation]] over the
|
||||
[[append-only-event-chain|signed chain]]). _(Analysis recorded 2026-06-21; implementation pending —
|
||||
see [[open-questions]] #12.)_
|
||||
|
||||
> ⚠ **Naming:** it's **TPM** (Trusted Platform Module), often miswritten "TMP".
|
||||
|
||||
## How it works — two primitives
|
||||
|
||||
1. **Non-extractable keys.** A key generated *inside* the TPM never leaves it. No command at any
|
||||
privilege level reads out the private key; you can only ask the TPM to *use* it (sign/decrypt).
|
||||
So the key isn't a file an attacker can copy — the same property the [[atecc608]] gives, but with
|
||||
hardware most PCs already have.
|
||||
2. **Boot measurement + sealing (PCRs).** Each boot stage hashes the next (firmware → bootloader →
|
||||
kernel) into tamper-evident registers (**PCRs**). A secret can be **sealed** so the TPM only
|
||||
releases/uses it when the PCRs match a known-good boot state — tamper the boot chain → PCRs change
|
||||
→ the TPM refuses.
|
||||
|
||||
## What it buys this appliance
|
||||
|
||||
- **Sealed-LUKS auto-unlock for unattended reboot.** The headline win. LUKS ([[disk-os-hardening]])
|
||||
normally needs a human to type a passphrase at boot; a parking booth must reboot itself after a
|
||||
power cut. `systemd-cryptenroll --tpm2-device` seals the LUKS key to the TPM + boot-chain PCRs, so
|
||||
the disk auto-unlocks **only** on an untampered boot. This is what makes "encrypted disk" and
|
||||
"unattended appliance" compatible.
|
||||
- **Defeats the offline disk-tamper / re-sign attack.** If the host event-signing key lives in the
|
||||
TPM (non-extractable), then pulling the SSD yields the *data* but **not** the signing key — so an
|
||||
attacker cannot edit a row and re-sign the chain. `verifyChain()` then catches every edit. (With a
|
||||
*software* signer the key sits in `.env` on the disk, so disk theft = key theft = forgeable; see
|
||||
[[append-only-event-chain]] "Signer abstraction".) Sealed-LUKS goes further: the disk won't even
|
||||
**mount** off-host, blocking the read step entirely.
|
||||
- **Boot tamper-evidence** complementing the already-decided Secure Boot + GRUB password
|
||||
([[disk-os-hardening]]).
|
||||
|
||||
## What it does NOT protect against (be honest about the limits)
|
||||
|
||||
- **A rooted *running* host.** The TPM stops key *theft*, not key *use*. An attacker with admin/root
|
||||
on the live appliance can still ask the TPM to sign — the chip signs for whoever the running OS
|
||||
authorizes. So a TPM does **not** make a compromised host trustworthy. (A per-op TPM auth PIN/policy
|
||||
raises this bar but a determined root can often capture it.) This is exactly why the load-bearing
|
||||
control stays [[reconciliation]] against an **external** authority that assumes the box may lie.
|
||||
- **Determined physical + BIOS access with tools.** Documented attacks exist:
|
||||
- **Bus sniffing** — a *discrete* TPM talks to the CPU over an external LPC/SPI bus; researchers
|
||||
have physically tapped it and captured secrets *as they're released* (e.g. the LUKS/BitLocker key
|
||||
in transit) on PCR-only-sealed systems. A **firmware TPM (fTPM)** inside the CPU has no external
|
||||
bus to sniff (but has had its own firmware bugs).
|
||||
- **TPM 1.2 is broken** (SHA-1) — require **2.0** only.
|
||||
- Vendor-specific firmware/reset/replay vulns have surfaced over the years.
|
||||
- **The operator (primary threat).** While the app runs, the DB is decrypted in memory and the
|
||||
operator acts *through* the authenticated app — encryption/sealing is irrelevant to "take the cash,
|
||||
void the record" ([[threat-model]]).
|
||||
- **Windows caveat.** On Windows the TPM serves BitLocker/Hello, not our Linux app; a Windows-admin
|
||||
attacker inherits Windows' long history of BitLocker-TPM bypasses. Another reason the Windows + WSL
|
||||
fallback ([[desktop-shell-tauri]]) is the weak deployment.
|
||||
|
||||
## Verdict & guidance
|
||||
|
||||
- **Recommended (not required)** on the **Ubuntu 26.04 LTS appliance** ([[desktop-shell-tauri|best
|
||||
case]]): use it for **sealed-LUKS auto-unlock + a non-extractable host event-signing key**. It is a
|
||||
**cost-raiser and theft-defeater, not an absolute vault.**
|
||||
- **Prefer a firmware TPM (fTPM)** (Intel PTT / AMD fTPM — no external bus to sniff) and add a
|
||||
**PIN/auth policy**, rather than PCR-only sealing.
|
||||
- **Operational hazard:** sealing to boot-chain PCRs means a *legitimate* kernel / GRUB / BIOS update
|
||||
also changes the PCRs and **locks you out** until re-sealed. Keep a **LUKS recovery passphrase** and
|
||||
a **re-seal-on-update runbook** — mandatory, and a reason this stays "enhancement," not "baseline".
|
||||
- **It complements, never replaces,** the [[append-only-event-chain|signed chain]] +
|
||||
[[reconciliation]].
|
||||
|
||||
## TPM vs. ATECC608 — which secure element for the signing key
|
||||
|
||||
Both can hold the non-extractable host event-signing key. Pick by platform:
|
||||
|
||||
| | **TPM 2.0** | **[[atecc608]]** |
|
||||
| --- | --- | --- |
|
||||
| In a typical PC? | **Often yes** (discrete or fTPM) | **No** — an external I²C part you add/solder |
|
||||
| Standard / integration | TCG standard, OS-integrated | Microchip part, app-integrated over I²C |
|
||||
| Best fit here | **PC-based host appliance** (use what's there) | **Embedded / [[esp32-custom-controller|ESP32]]** controller |
|
||||
| Tangled with the whole OS attack surface? | Yes (general-purpose) | Less so (single-purpose chip) |
|
||||
|
||||
**Implication (refines the prior framing):** the wiki/[[bom]] treated the ATECC608 as *the* host
|
||||
signing root, but for the **Ubuntu-PC appliance the TPM is the realistic host secure-element** (no
|
||||
extra part to source), with the **ATECC608 reserved for the embedded controller** where there's no
|
||||
TPM. Either delivers the tamper-*proof* property; see [[open-questions]] #6 (host secure-element by
|
||||
platform) and #12 (TPM hardening implementation).
|
||||
@@ -0,0 +1,164 @@
|
||||
---
|
||||
type: decision
|
||||
tags: [parking, decisions, desktop, frontend]
|
||||
sources: []
|
||||
updated: 2026-06-21
|
||||
status: settled
|
||||
---
|
||||
|
||||
# Desktop shell — Tauri v2 (chosen over Electron)
|
||||
|
||||
The operator UI ([[react-vite-spa]]) needs to ship as a **desktop application** on the
|
||||
appliance (kiosk-style), with a **mobile app possible later** but out of scope now. The choice
|
||||
was **Tauri v2 vs. Electron**. **Decision: Tauri v2.** _(Settled with the user, 2026-06-21.)_
|
||||
|
||||
## The thin-shell architecture (why this choice is low-risk)
|
||||
|
||||
The desktop shell is a **thin kiosk wrapper around the existing SPA**, nothing more. All
|
||||
privileged logic — device drivers ([[device-adapter-pattern]]: reader/printer/relay/serial),
|
||||
[[local-jwt-auth|auth]], the [[append-only-event-chain|signed ledger]], [[tariff]]/[[subscription]]
|
||||
pricing — **stays in the [[fastify]] server** (settled with the user, 2026-06-21). The shell only
|
||||
loads the SPA, which talks to the local Fastify server over localhost. Consequences:
|
||||
|
||||
- **No device/serial logic is ported into the shell** (no Rust device code for Tauri; no Node
|
||||
main-process drivers for Electron). The "logic lives in the server" invariant holds.
|
||||
- If a WebView quirk ever bites, the **blast radius is presentation only** — the server and its
|
||||
signed ledger are untouched.
|
||||
|
||||
This is what neutralizes Tauri's main weakness (host-WebView fragmentation, below): the shell's
|
||||
job is fullscreen chrome, autostart, and kiosk lockdown — not correctness-critical rendering of
|
||||
financial truth.
|
||||
|
||||
## Why Tauri v2 fits *this* project specifically
|
||||
|
||||
- **Threat-model alignment ([[threat-model]]).** The primary adversary is the operator at the
|
||||
booth. Tauri's **deny-by-default capability/permission model** means the renderer literally
|
||||
cannot reach the filesystem, shell, or any native command unless we hand it a named, allowlisted
|
||||
command. That is defense-in-depth that matches "don't trust the booth." Electron's equivalent
|
||||
hardening (`contextIsolation`, `nodeIntegration:false`, `sandbox:true`, strict CSP) is **opt-in
|
||||
and easy to misconfigure** into giving the renderer Node access — exactly what this threat model
|
||||
can't afford.
|
||||
- **Small footprint / smaller CVE surface.** Tauri uses the **OS WebView** (WebKitGTK on Linux) —
|
||||
~3–10 MB bundles, tens of MB RAM, and **no bundled Chromium** to patch. Electron ships and pins
|
||||
its own Chromium (100+ MB, hundreds of MB RAM) and makes us **own Chromium's CVE treadmill** on a
|
||||
long-lived appliance. On a [[disk-os-hardening|hardened]] single-purpose box maintained for
|
||||
years, less to patch is a real operational win.
|
||||
- **License.** Tauri is **MIT / Apache-2.0** — clears the hard MIT/Apache/BSD constraint
|
||||
([[technology-stack]]). (Electron is also MIT; not a differentiator.)
|
||||
- **Rust core** is available if device access ever *did* move shell-side — but per the decision
|
||||
above it does not, so this is latent upside, not a current cost.
|
||||
|
||||
## What Electron would have bought (the rejected upside)
|
||||
|
||||
- **Version-pinned bundled Chromium** → identical rendering everywhere regardless of host. The most
|
||||
predictable option on a locked-down appliance image, and the reason this isn't a slam-dunk.
|
||||
- Largest, most battle-tested kiosk/appliance ecosystem.
|
||||
- Node in the main process → trivial code-sharing with the Fastify/Node device drivers — but we
|
||||
explicitly **keep drivers in the server**, so this advantage doesn't apply here.
|
||||
|
||||
Rejected because the heavy footprint, the Chromium CVE-patching obligation, and the opt-in (easy
|
||||
to get wrong) security posture all cut against the appliance + threat-model constraints, while its
|
||||
one real advantage (bundled Chromium) is only conditionally needed — see the open question.
|
||||
|
||||
## Target deployment — best case vs. worst case
|
||||
|
||||
The decision's risk collapses to **which OS the appliance actually runs** (user, 2026-06-21):
|
||||
|
||||
- **Best case — Ubuntu 26.04 LTS desktop (the intended appliance).** Ships a **current,
|
||||
distro-maintained WebKitGTK** (`webkit2gtk-4.1` / GTK4), patched by Canonical for the LTS
|
||||
lifetime. This **closes** the WebView risk below — no ancient-WebView problem, no CVE-patching
|
||||
burden on us. A native, hardened, single-purpose box that matches the [[disk-os-hardening]]
|
||||
platform decision. **Tauri belongs here; the decision is unconditional in this world.**
|
||||
- **Worst case — Windows 11 + WSL + Docker.** This is **not** a "use Electron instead" fallback —
|
||||
it **contradicts the [[standing-decisions|standing platform decision]]** (explicitly *"a
|
||||
dedicated, hardened Linux appliance, **not Windows/WSL**"*) and undermines
|
||||
[[disk-os-hardening|Secure Boot / LUKS / tamper resistance]] against the booth operator
|
||||
([[threat-model]]). Moreover a **desktop GUI shell does not naturally live inside WSL/Docker**
|
||||
(both are headless Linux). The realistic shape there is **no native shell at all**: run
|
||||
[[fastify]] + the SPA in the WSL/Docker backend, and open the SPA in a **kiosk browser** on
|
||||
Windows (`msedge`/`chrome --kiosk --app=http://localhost:PORT`). Electron is warranted **only**
|
||||
if a self-contained installable Windows `.exe` (no system browser) is a hard requirement.
|
||||
|
||||
The **thin-shell architecture makes the worst-case fallback cheap**: because all logic lives in
|
||||
[[fastify]], dropping the shell for a kiosk browser costs only the native window wrapper, not any
|
||||
functionality.
|
||||
|
||||
| Deployment | Desktop shell |
|
||||
| --- | --- |
|
||||
| **Ubuntu 26.04 LTS** (best, intended) | **Tauri v2** — current WebKitGTK, native, hardened. Decision stands unconditionally. |
|
||||
| **Windows 11 + WSL + Docker** (worst, conflicts with platform decision) | **No native shell — kiosk browser** at the local Fastify-served SPA. Electron only if a standalone Windows installer is required. |
|
||||
|
||||
## The one thing to verify (procurement / image gate)
|
||||
|
||||
Tauri's rendering correctness depends on the **WebKitGTK version that ships on the target
|
||||
appliance OS image**. On a hardened/pinned image this can be old and cause rendering quirks — pin
|
||||
it and test the built SPA against that **exact** WebView. **On the intended Ubuntu 26.04 LTS this
|
||||
is effectively resolved** (current distro-maintained WebKitGTK); the concern only bites on an
|
||||
unexpected image with an ancient/unavailable WebView, which would point to the kiosk-browser path
|
||||
(or Electron) above. Tracked as an [[open-questions|open question]].
|
||||
|
||||
## Invariants this decision must preserve
|
||||
|
||||
1. **Server owns all privileged logic.** The shell is presentation only; device/auth/ledger/pricing
|
||||
stay in [[fastify]]. Don't let "convenient native access" pull driver logic into the shell.
|
||||
2. **Deny-by-default native surface.** Expose Tauri commands one at a time, allowlisted; never open
|
||||
a broad filesystem/shell capability to the renderer ([[threat-model]]).
|
||||
3. **[[offline-first]].** The shell, its updater, and any WebView must work air-gapped; no decision
|
||||
here may introduce a network dependency in core operation.
|
||||
4. **Mobile later, not now.** A future mobile app is a separate target; don't pre-build for it.
|
||||
|
||||
## As-built (scaffolded 2026-06-21)
|
||||
|
||||
`apps/desktop` — a Tauri v2 shell, its own pnpm/Turbo package, wrapping the **same** `apps/web`
|
||||
SPA so the desktop and browser UIs **cannot drift** (one UI codebase; requirement from the user):
|
||||
|
||||
- **Dev:** `tauri dev` loads `http://localhost:5173` (the `@parking/web` Vite dev server) →
|
||||
editing a component in `apps/web` updates the desktop window via HMR live. `beforeDevCommand`
|
||||
starts the web dev server.
|
||||
- **Prod:** `frontendDist: ../../web/dist` bundles the built SPA into the binary;
|
||||
`beforeBuildCommand` rebuilds it first.
|
||||
- **Backend origin:** the SPA used relative `/api` + a `window.location.host` WS URL — fine in a
|
||||
browser, broken from `tauri://localhost`. Centralized into `apps/web/src/lib/origin.ts`
|
||||
(`API_BASE`/`apiUrl`/`wsUrl`), read from **`VITE_API_BASE`** (empty in the browser = unchanged;
|
||||
set to the Fastify origin for the desktop build). The `tauri.conf.json` CSP `connect-src`
|
||||
whitelists `127.0.0.1:3000`/`localhost:3000` http+ws; the backend's `WS_ALLOWED_ORIGINS` must
|
||||
include the Tauri origin.
|
||||
- **Thin shell, enforced:** the Rust crate (`parking_desktop_lib::run`) registers **no commands**;
|
||||
the capability set is `core:default` only — no fs/shell/device access to the renderer
|
||||
(invariants 1–2). All logic stays in [[fastify]].
|
||||
- **Turbo:** `build` is a **no-op** (so `turbo run build` stays fast); the real bundle is a
|
||||
deliberate `pnpm --filter @parking/desktop bundle` (the vision-shim pattern).
|
||||
- **Verified:** `cargo check` + a full `tauri build` compiled the Rust/WebKitGTK/wry stack and
|
||||
produced working `.deb`/`.rpm`/`.AppImage` bundles; `pnpm turbo run build lint` → 14/14 green
|
||||
(was 12). All Linux prereqs present (Rust 1.93, WebKitGTK 4.1, libsoup-3, WSLg display).
|
||||
### Window / kiosk, auto-update, env (added 2026-06-21)
|
||||
|
||||
Per the user's choices — the operator **keeps OS access** (no fullscreen lockdown):
|
||||
|
||||
- **Window:** starts **maximized** (`maximized: true`), not fullscreen, resizable. No OS-key
|
||||
blocking, no always-on-top — the booth PC stays usable as a PC.
|
||||
- **Right-click:** the context menu is blocked in **prod only** (`apps/web/src/lib/kiosk.ts`,
|
||||
guarded on `import.meta.env.PROD`); dev keeps right-click + devtools. Applies to both the browser
|
||||
prod build and the desktop build (same SPA).
|
||||
- **`VITE_API_BASE` wired to the environment:** `apps/web/.env.production` (committed, non-secret,
|
||||
allow-listed in `.gitignore`) sets `VITE_API_BASE=http://127.0.0.1:3000`, auto-loaded by
|
||||
`vite build` (which the desktop bundle runs). So the desktop build targets Fastify with no manual
|
||||
export; the browser-served-by-Fastify build should override to `""`.
|
||||
- **Auto-update (prompt-on-update, self-hosted):** `tauri-plugin-updater` + `tauri-plugin-process`.
|
||||
On launch the SPA checks the endpoint (`apps/web/src/lib/desktop-updater.ts`, no-op in browser /
|
||||
offline), prompts the operator (i18n `update.prompt`), then `downloadAndInstall()` + `relaunch()`.
|
||||
Accepts that the appliance may be **offline** day-to-day and brought online (phone hotspot) only
|
||||
when an update is wanted — consistent with [[offline-first]] (no network dependency in *core*
|
||||
operation; updates are out-of-band). Endpoint in `tauri.conf.json` is a **placeholder**
|
||||
(`https://UPDATES.EXAMPLE.invalid/...`) to fill in once the self-hosted update URL exists; the
|
||||
server must serve `latest.json` + the signed installer + its `.sig`.
|
||||
- **Code-signing (updater):** an Ed25519 **updater keypair** was generated. The **public key is
|
||||
embedded** in `tauri.conf.json` (`plugins.updater.pubkey`); the **private key + password live
|
||||
OUTSIDE the repo** at `~/.parking-updater-keys/` (0600) and as the build-time secrets
|
||||
`TAURI_SIGNING_PRIVATE_KEY` / `TAURI_SIGNING_PRIVATE_KEY_PASSWORD`. Losing them means no future
|
||||
signed updates — back them up. **Verified:** a signed `pnpm --filter @parking/desktop bundle`
|
||||
produced `.deb`/`.rpm`/`.AppImage` **plus their `.sig` updater signatures**; full `turbo run build
|
||||
lint` 14/14 green. *(This is the **updater** signing — distinct from OS-installer signing for
|
||||
Windows/macOS "unknown publisher", and from the [[atecc608]]/[[tpm]] **event** signing.)*
|
||||
- **Still deferred:** the actual update-hosting URL, OS-level installer signing
|
||||
(Windows/macOS publisher trust), and the Windows kiosk-browser fallback path.
|
||||
@@ -2,14 +2,14 @@
|
||||
type: decision
|
||||
tags: [parking, decisions, open]
|
||||
sources: [parking-system-architecture]
|
||||
updated: 2026-06-15
|
||||
updated: 2026-06-21
|
||||
status: open
|
||||
---
|
||||
|
||||
# Open Questions / Next Steps
|
||||
|
||||
**Not yet decided**, and they drive everything else — settle before procurement. (See
|
||||
[[parking-system-architecture]] §10.)
|
||||
**Not yet decided** (or decided-but-not-yet-built), and they drive everything else — settle before
|
||||
procurement. (See [[parking-system-architecture]] §10.)
|
||||
|
||||
1. **Lane topology.** One host per lane, or one central host driving networked devices in each
|
||||
lane? Decides how many controllers, printers, UPSs, and [[sqlite]] instances exist, and the
|
||||
@@ -62,3 +62,36 @@ status: open
|
||||
reclaim deleted-blob pages without `VACUUM`. **Undecided:** pruning policy (age-based vs.
|
||||
total-size cap), VACUUM cadence, and how this interacts with the #5 backup strategy (blobs
|
||||
bloat every backup). Until decided, snapshots accumulate unbounded. See [[entry-exit-points]].
|
||||
11. **Appliance OS image → WebKitGTK version (Tauri dependency).** _(Raised by
|
||||
[[desktop-shell-tauri]], 2026-06-21; narrowed same day.)_ The chosen
|
||||
[[desktop-shell-tauri|Tauri v2 desktop shell]] renders through the **host's WebKitGTK**, not a
|
||||
bundled browser. The risk reduces to which OS the appliance runs:
|
||||
- **Best case — Ubuntu 26.04 LTS desktop (intended):** ships a current, distro-maintained
|
||||
WebKitGTK → this question is **effectively resolved**; just confirm the built SPA renders on
|
||||
the actual image and pin it.
|
||||
- **Worst case — Windows 11 + WSL + Docker:** this **conflicts with the standing platform
|
||||
decision** (Linux appliance, *not* Windows/WSL — see [[standing-decisions]],
|
||||
[[disk-os-hardening]]) and a GUI shell doesn't live inside headless WSL/Docker. Fallback is
|
||||
**no native shell — a kiosk browser** at the local [[fastify]]-served SPA (Electron only if a
|
||||
standalone Windows installer is mandated). See [[desktop-shell-tauri]] for the decision table.
|
||||
Close this once the appliance OS image is fixed and the SPA is verified against its WebView.
|
||||
(Ties to #1 lane topology / image standardization.)
|
||||
12. **TPM 2.0 hardening — implementation (to build).** _(Recorded 2026-06-21; analysis in [[tpm]].)_
|
||||
On the Ubuntu 26.04 LTS appliance, harden using the host **TPM**: (a) **sealed-LUKS auto-unlock**
|
||||
(`systemd-cryptenroll --tpm2-device`) so the encrypted disk auto-unlocks only on an untampered
|
||||
boot → unattended reboot after power loss; (b) optionally hold the **non-extractable host
|
||||
event-signing key** in the TPM (a new `Signer` impl — no `EventLog` change; mirrors the
|
||||
[[atecc608]] swap), defeating the offline pull-the-disk-and-re-sign attack. **Must include:**
|
||||
require **TPM 2.0** (reject 1.2), **prefer fTPM** + a per-op **PIN/auth policy** (not PCR-only —
|
||||
bus-sniff), a **LUKS recovery passphrase**, and a **re-seal-on-update runbook** (kernel/GRUB/BIOS
|
||||
updates change the PCRs and lock the disk). TPM **complements, never replaces**, [[reconciliation]];
|
||||
it does nothing against a rooted live host or the operator. Moot in the Windows + WSL fallback. See
|
||||
[[tpm]], [[disk-os-hardening]]; relates to #6 (host secure-element by platform) and #13.
|
||||
13. **Startup chain-integrity self-check (to build).** _(Raised by the pull-the-disk trace,
|
||||
2026-06-21.)_ `verifyChain()` exists and pinpoints any tamper, but **nothing invokes it on
|
||||
boot** — a tampered DB loads and serves normally (detectable but undetected). Wire a **startup
|
||||
self-check** that runs `verifyChain()` and, on a break, **flags degraded state / writes a signed
|
||||
`anomaly` + alarms** (surfaced to the booth footer / next reconciliation). Open: refuse-to-serve
|
||||
vs. serve-degraded — lean **serve-degraded + loud alarm** (fail-open on exit still governs;
|
||||
refusing to boot could strand a lane). Software-only, independent of the TPM/[[atecc608]] hardware.
|
||||
See [[append-only-event-chain]].
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
type: decision
|
||||
tags: [parking, decisions]
|
||||
sources: [parking-system-architecture]
|
||||
updated: 2026-06-14
|
||||
updated: 2026-06-21
|
||||
status: settled
|
||||
---
|
||||
|
||||
@@ -20,6 +20,11 @@ The decisions treated as settled in the design notes. (See [[parking-system-arch
|
||||
[[vision-service]].
|
||||
- **Platform:** a **dedicated, hardened Linux appliance** (LUKS + GRUB password + Secure Boot),
|
||||
**not Windows/WSL** — see [[disk-os-hardening]].
|
||||
- **Desktop shell:** the operator UI ships as a **[[desktop-shell-tauri|Tauri v2]]** kiosk wrapper
|
||||
(chosen over Electron, 2026-06-21) — small footprint, no bundled Chromium to patch, and a
|
||||
deny-by-default native surface that fits [[threat-model|the booth-operator threat model]]. The
|
||||
shell stays **thin**: all privileged logic remains in [[fastify]]. One open dependency — the
|
||||
appliance's WebKitGTK version (see [[open-questions]] #11).
|
||||
- **Integrity:** append-only, hash-chained, [[atecc608]]-signed event log
|
||||
([[append-only-event-chain]]); **[[reconciliation]] is the anti-fraud control**; encryption
|
||||
protects only at-rest (see [[threat-model]]).
|
||||
|
||||
@@ -22,3 +22,11 @@ Two distinct uses:
|
||||
|
||||
Confirming ATECC608 wiring/usage on both ends is [[open-questions]] #6. Listed in the [[bom]]
|
||||
on the host machine.
|
||||
|
||||
> **Platform caveat (2026-06-21):** the ATECC608 is **not a PC component** — it's an external I²C
|
||||
> secure element you add/solder, native to embedded boards (the [[esp32-custom-controller]]), not to
|
||||
> an off-the-shelf host PC. For a **PC-based appliance** the realistic host secure-element for the
|
||||
> non-extractable event-signing key is the **[[tpm|TPM 2.0]]** the machine likely already has; reserve
|
||||
> the ATECC608 for the embedded controller. Both give the same non-extractable property — see [[tpm]]
|
||||
> "TPM vs. ATECC608". So use #1 (host event signing) is **TPM on a PC, ATECC608 on embedded**; use #2
|
||||
> (controller command auth) stays ATECC608.
|
||||
|
||||
+4
-2
@@ -1,13 +1,13 @@
|
||||
---
|
||||
type: overview
|
||||
tags: [parking, index]
|
||||
updated: 2026-06-19
|
||||
updated: 2026-06-21
|
||||
---
|
||||
|
||||
# Index
|
||||
|
||||
Content catalog for the wiki. Start at [[overview]]. Maintained on every ingest.
|
||||
Counts: 4 sources · 19 entities · 44 concepts · 6 decision records.
|
||||
Counts: 4 sources · 19 entities · 45 concepts · 7 decision records.
|
||||
|
||||
## Overview & navigation
|
||||
- [[overview]] — the top-level synthesis and entry point.
|
||||
@@ -49,6 +49,7 @@ Counts: 4 sources · 19 entities · 44 concepts · 6 decision records.
|
||||
## Concepts — foundational forces
|
||||
- [[offline-first]] — no network dependency in core operation; what it forces (and doesn't).
|
||||
- [[threat-model]] — the operator-at-the-booth reframing; why encryption defends the wrong threat.
|
||||
- [[tpm]] — TPM 2.0 hardening: how it works, sealed-LUKS auto-unlock + non-extractable signing key; limits (live-root, bus-sniff) + TPM-vs-ATECC608 by platform; complements, not replaces, reconciliation.
|
||||
|
||||
## Concepts — integrity & anti-fraud
|
||||
- [[append-only-event-chain]] — append-only + hash chain + ATECC608 signing = unforgeable log.
|
||||
@@ -117,3 +118,4 @@ Counts: 4 sources · 19 entities · 44 concepts · 6 decision records.
|
||||
- [[vision-service]] — build a host-side ANPR + vehicle-verification service; replaces edge-LPR; scoped AGPL exception.
|
||||
- [[vision-service-packaging]] — the vision service lives in this monorepo (apps/vision/), separate process, wired into Turbo via a package.json shim; uv-managed Python.
|
||||
- [[event-streams-split]] — split the signed business ledger (ledger_events) from unsigned device telemetry (device_events).
|
||||
- [[desktop-shell-tauri]] — ✅ Tauri v2 chosen over Electron for the desktop kiosk shell; thin wrapper, server keeps all logic. Best case Ubuntu 26.04 LTS (resolves WebKitGTK); worst case Windows+WSL → kiosk browser, no native shell.
|
||||
|
||||
+56
@@ -1173,3 +1173,59 @@ reserve checkbox (SiteSettings); booth pay modal shows an "OUT-OF-WINDOW" charge
|
||||
Verified on a copy of the live DB: qty 2 = 2× price; night-plan 19:30 entry → 30min/15,000 ALL owed,
|
||||
stamped + paid → gate clears, chain verifies; reserve toggle holds a qty-2 sub's 2 spots. Build+lint
|
||||
12/12; 80 shared tests. Updated [[subscription]], [[capacity-occupancy]], [[tariff]].
|
||||
|
||||
## [2026-06-21] query | Desktop shell: Tauri v2 vs. Electron
|
||||
Compared Tauri v2 and Electron for shipping the operator UI as a desktop app (mobile deferred).
|
||||
Decision (with user): **Tauri v2** — small footprint, no bundled Chromium to patch, deny-by-default
|
||||
native surface fitting the booth-operator threat model; MIT/Apache. Shell stays thin (device/auth/
|
||||
ledger/pricing remain in Fastify, per user). Filed [[desktop-shell-tauri]]; cross-linked from
|
||||
[[standing-decisions]], [[overview]], [[index]]. Open dependency: appliance WebKitGTK version
|
||||
([[open-questions]] #11) — flips to Electron if ancient/unavailable.
|
||||
|
||||
## [2026-06-21] query | Desktop shell — target OS (best/worst case)
|
||||
User specified deployment span: best = Ubuntu 26.04 LTS desktop, worst = Windows 11 + WSL + Docker.
|
||||
Refined [[desktop-shell-tauri]] + [[open-questions]] #11: Ubuntu 26.04 LTS ships a current
|
||||
distro-maintained WebKitGTK → effectively closes the WebView risk; Tauri unconditional there. The
|
||||
Windows+WSL case is NOT an "Electron instead" fallback — it conflicts with the standing Linux-
|
||||
appliance platform decision and can't host a GUI shell in headless WSL/Docker; fallback is a kiosk
|
||||
browser at the local Fastify-served SPA (Electron only if a standalone Windows installer is
|
||||
mandated). Thin-shell architecture makes that fallback cheap.
|
||||
|
||||
## [2026-06-21] query | TPM 2.0 hardening — analysis + pull-the-disk attack trace
|
||||
How a TPM works (non-extractable keys + PCR sealing) and its limits, recorded after tracing the
|
||||
"pull the SSD, tamper parking.sqlite offline, reboot" attack against event-log.ts/signer.ts.
|
||||
Findings: verifyChain() catches every blind tamper (bad sig / index gap / prevHash / unknown keyId)
|
||||
but (a) nothing runs it at boot, and (b) the software HMAC key lives in .env on the same disk →
|
||||
attacker can re-sign undetectably. Only a secure-element key (TPM on a PC, ATECC608 on embedded)
|
||||
makes it tamper-PROOF; TPM-sealed LUKS additionally blocks off-host mount. TPM verdict: recommended
|
||||
not required on the Ubuntu appliance (sealed-LUKS auto-unlock + non-extractable signing key); does
|
||||
NOT defend a rooted live host or the operator; bus-sniff/PCR-brittleness caveats → prefer fTPM + PIN,
|
||||
keep recovery passphrase + re-seal runbook; complements not replaces reconciliation. Also corrected:
|
||||
ATECC608 is NOT in a PC (external I²C part) → on a PC appliance the TPM is the host secure-element,
|
||||
ATECC608 reserved for the ESP32 controller. New page [[tpm]]; cross-linked [[disk-os-hardening]],
|
||||
[[threat-model]], [[atecc608]], [[append-only-event-chain]]; open-questions #12 (TPM impl, to build),
|
||||
#13 (startup verifyChain self-check, to build); index + counts updated.
|
||||
|
||||
## [2026-06-21] build | apps/desktop — Tauri v2 kiosk shell scaffolded
|
||||
Built the thin Tauri v2 shell per [[desktop-shell-tauri]]: new apps/desktop package wrapping the
|
||||
SAME apps/web SPA (dev → localhost:5173 with HMR; prod → bundled web dist/), so desktop and browser
|
||||
UIs can't drift (user requirement). Rust core holds no business logic; capabilities core:default
|
||||
only (deny-by-default). One apps/web change: centralized the backend origin into lib/origin.ts
|
||||
(API_BASE/apiUrl/wsUrl from VITE_API_BASE) — no-op in the browser, lets the Tauri build target the
|
||||
Fastify origin. Turbo build is a no-op; real bundle = `pnpm --filter @parking/desktop bundle`.
|
||||
VERIFIED: cargo check + full tauri build → working .deb/.rpm/.AppImage; turbo run build lint 14/14
|
||||
green; prereqs present (Rust 1.93, WebKitGTK 4.1, libsoup-3, WSLg). Filled the As-built section of
|
||||
[[desktop-shell-tauri]]. Deferred: kiosk lockdown, auto-update, signing, Windows kiosk-browser path.
|
||||
|
||||
## [2026-06-21] build | apps/desktop — window/right-click, auto-update, code-signing, env wiring
|
||||
Per user choices on the Tauri shell: window starts MAXIMIZED (not fullscreen — operator keeps OS
|
||||
access); right-click context menu blocked in PROD only (lib/kiosk.ts, dev keeps devtools).
|
||||
VITE_API_BASE wired via apps/web/.env.production (committed non-secret, allow-listed in .gitignore;
|
||||
auto-loaded by vite build → desktop bundle targets Fastify, no manual export). Auto-update built:
|
||||
tauri-plugin-updater + -process, prompt-on-update flow (lib/desktop-updater.ts, no-op in browser/
|
||||
offline) → downloadAndInstall + relaunch; endpoint is a self-hosted PLACEHOLDER to fill in. Updater
|
||||
keypair generated: pubkey embedded in tauri.conf.json; private key + password kept OUTSIDE the repo
|
||||
(~/.parking-updater-keys, 0600) + as TAURI_SIGNING_* build secrets. VERIFIED: signed bundle →
|
||||
.deb/.rpm/.AppImage + .sig updater signatures; turbo run build lint 14/14 green; no key material in
|
||||
the repo. Updated As-built in [[desktop-shell-tauri]]. Deferred: real update URL, OS installer
|
||||
signing, Windows kiosk-browser fallback.
|
||||
|
||||
+3
-2
@@ -2,7 +2,7 @@
|
||||
type: overview
|
||||
tags: [parking, overview, synthesis]
|
||||
sources: [parking-system-architecture]
|
||||
updated: 2026-06-14
|
||||
updated: 2026-06-21
|
||||
---
|
||||
|
||||
# Parking System — Overview
|
||||
@@ -23,7 +23,8 @@ deployed on-site at a parking facility. Two forces shape nearly every decision:
|
||||
|
||||
- **Stack** ([[technology-stack]] / [[standing-decisions]]): [[turborepo]] · [[fastify]] ·
|
||||
[[react-vite-spa]] · [[sqlite]] + [[drizzle-orm]] · [[local-jwt-auth]] — all open-licensed to
|
||||
avoid lock-in (cf. rejected [[payload-cms]], [[refine]], [[logto-zitadel-oidc]]).
|
||||
avoid lock-in (cf. rejected [[payload-cms]], [[refine]], [[logto-zitadel-oidc]]). The operator UI
|
||||
ships as a thin **[[desktop-shell-tauri|Tauri v2]]** kiosk shell (chosen over Electron).
|
||||
- **Integrity** is the heart of it: an [[append-only-event-chain]] (hash-chained, [[atecc608]]-
|
||||
signed) plus external [[reconciliation]] — *that's* what remote sync really is. Encryption at
|
||||
rest ([[disk-os-hardening]]) defends a secondary threat.
|
||||
|
||||
Reference in New Issue
Block a user