f6cfe382fd
The host has known how to answer "is a newer build available for this box's channel?" since the update-from-web-console work. The Linux client is about to need the same answer from the same signed document, and a trust rule that lives in two places is a trust rule that will drift. So the parts where being wrong is a security bug now exist exactly once, in the new `pf-update-check`: Ed25519 verification against pinned keys, the manifest schema and its fail-closed validation, the post-redirect fetch, the version comparison that has to reconcile four different canary spellings, and the install-kind ladder — the last parameterised by which product is asking, since the delivery channels are the same ones but the markers are not. The pinned key list moves with them. Two lists could have disagreed about who may announce a release, and the one that drifted is the one nobody would have noticed; `publish-update-manifest.sh` follows to the new path, and a MISSING keys file there is now fatal rather than a warning that silently skips the cross-check the step exists to perform. Host call sites are unchanged throughout: `store::index` and `update::manifest` re-export from the shared crate under their old names, and `update::detect` keeps its cached `detect()` and the host's command hints. Verified with clippy -D warnings on Linux and on Windows (nvenc,amf-qsv,qsv), 340 host tests green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
35 lines
1.6 KiB
TOML
35 lines
1.6 KiB
TOML
# The update-CHECK core, shared by the host and the Linux client (planning:
|
|
# host-update-from-web-console.md §3). It exists because both products answer the same
|
|
# question — "does a newer build exist for this box's channel?" — from the same signed
|
|
# manifest, and a trust rule that lives in two places is a trust rule that will diverge.
|
|
#
|
|
# Deliberately check-only: no apply legs, no package managers, no privileged anything. The
|
|
# host keeps its Windows/Linux apply code; the client keeps its own. What is shared here is
|
|
# exactly the part where being wrong is a security bug: signature verification, manifest
|
|
# validation, and the version comparison that decides whether to tell a user to update.
|
|
[package]
|
|
name = "pf-update-check"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
rust-version.workspace = true
|
|
license.workspace = true
|
|
authors.workspace = true
|
|
repository.workspace = true
|
|
description = "Signed update-manifest fetch + verification, install-kind detection and version comparison, shared by the punktfunk host and client."
|
|
publish = false
|
|
|
|
[dependencies]
|
|
anyhow = "1"
|
|
serde = { version = "1", features = ["derive"] }
|
|
serde_json = "1"
|
|
# Ed25519 over the exact manifest bytes. The workspace is ring-only (no aws-lc-sys — it fails
|
|
# on the Windows CI runner), and this is the same primitive the plugin-store index uses.
|
|
ring = "0.17"
|
|
base64 = "0.22"
|
|
# Small, sync, bundles webpki roots — no system cert store dependency, which matters on the
|
|
# Deck (Decky's embedded Python has no usable roots either; see clients/decky/main.py).
|
|
ureq = "2"
|
|
|
|
[lints]
|
|
workspace = true
|