BetterCorp/BetterFrame
1
0
Fork 0
mirror of https://github.com/BetterCorp/BetterFrame.git synced 2026-05-26 20:16:35 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10
BetterFrame/kiosk/Cargo.toml

62 lines
1.7 KiB
TOML
Raw Normal View History

feat: Rust kiosk app — GTK4 + GStreamer multi-camera display - Server discovery (localhost → betterframe.local → cloud) - Pairing flow with fullscreen code display - Bundle fetch and layout rendering - GTK4 Grid layout matching template regions - GStreamer pipelines per camera cell via gtk4paintablesink - Heartbeat loop in background thread - Placeholder widgets for web/html cells
2026-05-10 02:18:40 +00:00
[package]
name = "betterframe-kiosk"
version = "0.1.0"
edition = "2024"
description = "BetterFrame kiosk — multi-camera display with GTK4 + GStreamer"
license = "AGPL-3.0-only OR Commercial"
[dependencies]
chore: target latest-stable everywhere — Debian Trixie + gtk4 v4_14 - CI workflow container: debian:trixie-slim (was bookworm-slim) - Server image base: node:23-trixie-slim (was bookworm-slim) - Kiosk Cargo.toml: gtk4 features v4_14 (was v4_8) — matches Trixie's stock gtk 4.14 without backports juggling - setup-pi-kiosk.sh header: Trixie+ target (was Bookworm+) Glibc matches across Pi OS Trixie, Coolify host (Trixie), CI build container — no symbol drift at runtime.
2026-05-19 02:21:14 +00:00
# GTK4 for windowing/layout. v4_14 = Debian Trixie / Pi OS Trixie stock
ci(pi-gen): trixie everywhere + missing prerun.sh + EXPORT_IMAGE marker Reverts misdiagnosis. pi-gen defaults to trixie since the Debian 13 release, which has gtk4 4.14 + libwebkitgtk-6.0 stock — no backports needed. Build container, kiosk gtk feature gate, and pi-gen target all realigned to trixie. Actual reason last image run failed: our custom stage was missing the mandatory prerun.sh (pi-gen calls it to seed ROOTFS_DIR from the previous stage) and the EXPORT_IMAGE marker file (signals 'bake an image at the end of this stage'). Both added. Asset upload now globs deploy/*.img.xz so any extra exports stage2 produces ship alongside our customised one.
2026-05-19 03:19:32 +00:00
# libgtk-4 — pi-gen defaults to trixie, so build chain + image are aligned.
chore: target latest-stable everywhere — Debian Trixie + gtk4 v4_14 - CI workflow container: debian:trixie-slim (was bookworm-slim) - Server image base: node:23-trixie-slim (was bookworm-slim) - Kiosk Cargo.toml: gtk4 features v4_14 (was v4_8) — matches Trixie's stock gtk 4.14 without backports juggling - setup-pi-kiosk.sh header: Trixie+ target (was Bookworm+) Glibc matches across Pi OS Trixie, Coolify host (Trixie), CI build container — no symbol drift at runtime.
2026-05-19 02:21:14 +00:00
gtk4 = { version = "0.9", features = ["v4_14"] }
feat: Rust kiosk app — GTK4 + GStreamer multi-camera display - Server discovery (localhost → betterframe.local → cloud) - Pairing flow with fullscreen code display - Bundle fetch and layout rendering - GTK4 Grid layout matching template regions - GStreamer pipelines per camera cell via gtk4paintablesink - Heartbeat loop in background thread - Placeholder widgets for web/html cells
2026-05-10 02:18:40 +00:00
# GStreamer for RTSP decode
gstreamer = "0.23"
gstreamer-video = "0.23"
gst-plugin-gtk4 = "0.13"
# HTTP client for server API
reqwest = { version = "0.12", features = ["json", "blocking"] }
# JSON
serde = { version = "1", features = ["derive"] }
serde_json = "1"
# Async runtime
tokio = { version = "1", features = ["rt-multi-thread", "macros", "time", "fs"] }
# Misc
dirs = "6"
tracing = "0.1"
fix: resolve all Rust compile errors in kiosk app
2026-05-10 18:04:43 +00:00
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
hostname = "0.4"
feat: live updates via WebSocket — server pushes, kiosk reloads Server side: - service-coordinator-ws: full WS implementation using ws package - Auth via ?token=<kiosk_key> query param - Coordinator registry for cross-plugin notification - Admin mutations call notifyKiosks() → server pushes reload-bundle - 30s ping/pong heartbeat Kiosk side: - Rust ws_client with tokio runtime + tokio-tungstenite - Auto-reconnect with exponential backoff (1s → 60s cap) - On reload-bundle: re-fetches bundle, re-renders layout - Pong replies to server pings Also fix: auto-suffix kiosk name on UNIQUE collision (re-pair with same hostname no longer fails).
2026-05-10 20:15:58 +00:00
tokio-tungstenite = { version = "0.24", features = ["native-tls"] }
futures-util = "0.3"
url = "2"
feat: WebKit for web/html cells + display auto-discovery via heartbeat Rust kiosk: - web cells now use webkit6 WebView (load_uri) - html cells use WebView.load_html (full HTML rendering) - query_displays() reads /sys/class/drm/ for connected HDMI/DP outputs - Heartbeat reports display geometry every 60s Server: - /api/kiosk/heartbeat accepts displays array - Syncs kiosk-reported displays to display records - Updates dimensions when changed, creates new displays for new ports
2026-05-10 20:39:53 +00:00
webkit6 = "0.4"
feat: multi-display + snapshot + health + GPIO + nodered embed Multi-display: - Bundle ships displays[] each with own layouts + idle/sleep - Rust kiosk creates one ApplicationWindow per gdk monitor - Per-display state (layout, idle, sleep) via HashMap - WARM_CAMERAS pool shared across displays - Backward-compat top-level display/layouts still emitted System Health (/admin/health): - Online status, CPU temp (color-coded), fan RPM/PWM - Bundle version mismatch detection - 30s auto-refresh Camera snapshot/test: - shared/snapshot.ts: ffmpeg/gst-launch fallback, 5s timeout - /admin/entities/:id/snapshot returns JPEG - EntityEditPage shows live preview with Refresh GPIO (Pi buttons/sensors): - kiosk_gpio_bindings table + CRUD admin UI - Bundle ships gpio_bindings[] - kiosk/src/gpio.rs with gpiod crate, worker thread per pin - Edge events POST to /api/kiosk/event with source_type=gpio Layout switch fixes: - GET aliases added so direct URL hits work - New /admin/displays/:displayId/layout/:layoutId for multi-display - DisplayEditPage gets "Switch Layout Now" section Node-RED embed: - /admin/nodered renders iframe at /nrdp/ - Sandbox attrs allow scripts/forms/popups - Sidebar link now opens embedded view
2026-05-12 23:18:22 +00:00
gpiod = "0.3"
feat(ota): replacement pairing + firmware OTA (admin UI, kiosk client, CI)
2026-05-13 18:56:42 +00:00
# OTA firmware update: sha256 + Ed25519 signature verify
sha2 = "0.10"
ed25519-dalek = { version = "2", features = ["pem"] }
base64 = "0.22"
feat(os-ota): kiosk-side RAUC bundle consumer Phase 3 of the OS OTA pipeline. New module kiosk/src/os_update.rs polls /api/kiosk/os/check with the kiosk's compatibility string and current OS version (read from /etc/betterframe/os-compatibility + /etc/betterframe/os-version, both written by the image build), downloads the bundle, sha256-verifies the transport, and hands off to `rauc install`. RAUC takes it from there: CMS signature verify against /etc/rauc/keyring.pem, copy into inactive A/B slot, arm tryboot via the custom bootloader backend, return. We then post /api/kiosk/os/applied and `systemctl reboot` into the new slot. Wired into the existing 60s heartbeat loop in ui.rs, gated by BF_ENABLE_OS_OTA=1 (default OFF so dev kiosks on non-A/B images don't keep trying + failing). Runs BEFORE the kiosk-binary check on each tick so an OS bundle that ships an updated kiosk binary doesn't race the firmware path. On clean-boot heartbeat success we now also call `rauc status mark-good` so the boot-attempts counter resets — three bad boots in a row will auto-roll back without us needing a separate rollback path. What's NOT in this commit: - A/B partition layout in the pi-gen image (task #6, blocks actual deployment — bundles can be served + accepted but `rauc install` will refuse without two valid slots). - Admin UI for managing releases + rollouts (task #4).
2026-05-21 08:47:45 +00:00
urlencoding = "2"
feat(kiosk): LAN-side local HTTP server (GET layout API + admin proxy) Kiosk now exposes :18090 with two surfaces: - GET /local/layout/:id?key=<kiosk_local_key> Bookmark-friendly layout switch on this kiosk. Auth = kiosk-generated local key (32 random bytes, hex, stored at <state_dir>/local.key). - ANY /proxy/* — forwards to BF server with the request's Authorization header preserved. Lets LAN clients reach a cloud-hosted BF server via the kiosk's local socket; kiosk adds no auth of its own. Heartbeat reports {local_key, local_port}; kiosks table grows local_key/local_port/local_last_ip columns. Admin kiosk edit page now shows the local URLs as a copy-paste block. Override port: BF_KIOSK_LOCAL_PORT. Disable: BF_KIOSK_LOCAL_DISABLE=1.
2026-05-14 05:24:21 +00:00
feat(onvif-events): PullPoint subscription for all ONVIF cameras New kiosk/src/onvif_events.rs: for each ONVIF camera in the bundle, creates a PullPoint subscription, polls every 3s, parses NotificationMessage XML into structured JSON (topic + source key/values + data key/values + timestamp), and POSTs to /api/kiosk/event with source_type=onvif + camera_id. Forwards ALL event topics: motion, ANPR (LicensePlateRecognition), line crossing, intrusion, digital input, analytics, tamper — everything the camera exposes. Node-RED sorts what matters. Subscription lifecycle: - CreatePullPointSubscription with 60s InitialTerminationTime - Renew every 55s before timeout - Unsubscribe on bundle change / shutdown - Auto-resubscribe on pull/renew failure (30s backoff) - Generation tracking via Weak<()> so old workers self-terminate when start() is called with a new bundle WSSE PasswordDigest auth for SOAP calls — same scheme the server's onvif.ts uses. sha1 crate added. BundleCamera extended with onvif_host/port/username/password_encrypted fields (server already ships them; kiosk just wasn't deserializing). Gated by BF_ENABLE_ONVIF_EVENTS=1. Enabled by default in the pi-gen image env file. TODO: cluster-key-based decryption of onvif_password_encrypted. For now relies on the RTSP URI having plaintext credentials embedded (which the ONVIF import path already ensures via rtspWithCredentials).
2026-05-21 10:03:30 +00:00
# ONVIF WSSE PasswordDigest auth
sha1 = "0.10"
refactor(kiosk): migrate all bundle IDs to String for UUIDv7 + ONVIF image proxy - All bundle struct ID fields (kiosk_id, display_id, layout_id, camera_id, stream_id, gpio_id) now String with de_flexible_id deserializer accepting both JSON numbers and strings. - PoolKey, DisplayState hashmap, WorkerMsg, ServerMsg all use String IDs throughout. Zero u32 ID references remain. - ONVIF event image proxy: kiosk detects PictureUri in event data, downloads image from camera (basic/digest auth), base64 encodes, attaches to event payload before forwarding to server. - Add md5 crate for HTTP Digest auth on camera image fetch. - ws_client: flexible_id_from_value helper for WS message ID parsing. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-05-26 11:09:32 +00:00
# HTTP Digest auth for camera image fetch
md5 = "0.7"
feat(onvif-events): PullPoint subscription for all ONVIF cameras New kiosk/src/onvif_events.rs: for each ONVIF camera in the bundle, creates a PullPoint subscription, polls every 3s, parses NotificationMessage XML into structured JSON (topic + source key/values + data key/values + timestamp), and POSTs to /api/kiosk/event with source_type=onvif + camera_id. Forwards ALL event topics: motion, ANPR (LicensePlateRecognition), line crossing, intrusion, digital input, analytics, tamper — everything the camera exposes. Node-RED sorts what matters. Subscription lifecycle: - CreatePullPointSubscription with 60s InitialTerminationTime - Renew every 55s before timeout - Unsubscribe on bundle change / shutdown - Auto-resubscribe on pull/renew failure (30s backoff) - Generation tracking via Weak<()> so old workers self-terminate when start() is called with a new bundle WSSE PasswordDigest auth for SOAP calls — same scheme the server's onvif.ts uses. sha1 crate added. BundleCamera extended with onvif_host/port/username/password_encrypted fields (server already ships them; kiosk just wasn't deserializing). Gated by BF_ENABLE_ONVIF_EVENTS=1. Enabled by default in the pi-gen image env file. TODO: cluster-key-based decryption of onvif_password_encrypted. For now relies on the RTSP URI having plaintext credentials embedded (which the ONVIF import path already ensures via rtspWithCredentials).
2026-05-21 10:03:30 +00:00
feat(harden): hardware-bound at-rest encryption of kiosk state files New module kiosk/src/at_rest.rs. Derives an AES-256-GCM key via HKDF from a Pi-bound value: 1. /proc/device-tree/serial-number (Pi 5 firmware exposes it) 2. /proc/cpuinfo Serial line (older kernels) 3. /etc/machine-id (non-Pi dev fallback) File format: "BFE1" magic || 12-byte random nonce || ciphertext+tag. Atomic write via tempfile + rename so a crash mid-write can't leave a half-encrypted file. Wired into kiosk/src/server.rs at every file I/O touching sensitive state: - kiosk.key (bearer token to BF server) - local.key (LAN-side API auth key) - bundle.json (cached bundle with RTSP credentials in URL form) Migration: read paths tolerate legacy plaintext (kiosks upgraded from a pre-at_rest build) AND re-store as ciphertext on the first read. One- shot upgrade — subsequent boots skip the migration write. Threat model defended: SD card extraction. Attacker who pulls the card can't decrypt without also having the same physical Pi (CPU serial is hardware-bound). Doesn't defeat an attacker who has both — at that point they ARE the kiosk. Bar is raised from "trivially extract every camera password" to "must steal the device intact." Not defended: TPM-style attestation, remote attestation, sealed boot. Pi 5 has no TPM and we don't ship a secure-boot config. Tests in-module: round-trip short bytes, round-trip JSON, legacy plaintext passthrough.
2026-05-21 09:34:29 +00:00
# Hardware-bound at-rest encryption of state files (kiosk_key + bundle cache
# contain camera RTSP credentials in URL form). Keys derived via HKDF from
# the Pi CPU serial — pulling the SD doesn't yield plaintext without also
# having the same physical board.
aes-gcm = "0.10"
hkdf = "0.12"
feat(kiosk): LAN-side local HTTP server (GET layout API + admin proxy) Kiosk now exposes :18090 with two surfaces: - GET /local/layout/:id?key=<kiosk_local_key> Bookmark-friendly layout switch on this kiosk. Auth = kiosk-generated local key (32 random bytes, hex, stored at <state_dir>/local.key). - ANY /proxy/* — forwards to BF server with the request's Authorization header preserved. Lets LAN clients reach a cloud-hosted BF server via the kiosk's local socket; kiosk adds no auth of its own. Heartbeat reports {local_key, local_port}; kiosks table grows local_key/local_port/local_last_ip columns. Admin kiosk edit page now shows the local URLs as a copy-paste block. Override port: BF_KIOSK_LOCAL_PORT. Disable: BF_KIOSK_LOCAL_DISABLE=1.
2026-05-14 05:24:21 +00:00
# Local HTTP server on kiosk (LAN GET-only layout switch + admin proxy)
axum = "0.7"
tower = "0.5"
hex = "0.4"
rand = "0.8"
Reference in a new issue Copy permalink