296 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	f34f311c69	Merge pull request 'fix(brand): capitalize "Punktfunk" in user-facing text; name the legal copyright holder' (#81) from worktree-docs-title-casing into main ... Reviewed-on: #81	2026-08-06 21:33:33 +00:00
enricobuehler	e6bcac8770	chore(license): name the copyright holder "unom - Enrico Bühler" ... "unom" alone is not the legal entity name. Updated the copyright line in all nine first-party license files -- the root MIT/Apache pair and the hand-maintained copies under clients/apple, clients/decky, packaging/windows/drivers and packaging/windows/pf-vkhdr-layer (there is no script that syncs these, so each is edited directly). The Linux and Windows clients' About screens pick this up automatically: both `include_str!` the root LICENSE-MIT / LICENSE-APACHE at compile time. Deliberately untouched: - Third-party license texts (Geist OFL, FFmpeg, VB-CABLE, the vendored pyrowave/Granite tree, KDE protocol XMLs, the os-icon licenses) -- those are other parties' copyrights. - Publisher/author/maintainer metadata, which is identity rather than license text and is reported separately for a decision.	2026-08-06 23:16:16 +02:00
enricobuehler	b0ec759fad	fix(brand): capitalize "Punktfunk" in user-facing text ... The docs site's page title read "punktfunk docs". Fixed that and swept the rest of the tree for the same defect, capitalizing the brand wherever it is shown to a human and leaving it lowercase where it is a technical identifier (CLI/package names, `punktfunk://` scheme, PnP enumerator, TLS SNI, logcat tag, config paths, CMS tenant id). User-visible fixes: - docs-site: page title -> "Punktfunk Docs"; API reference title, meta description and the branded bar's aria-label; the BrandMark/Wordmark SVG accessible names (the web console already had these capitalized -- the docs site had drifted from it). - Android: six strings of live UI copy -- the local-network permission dialog (x2), the connect-screen error banner, and the no-controller explainer. - Apple: the "No Hosts" empty-state text and the fallback display name for a host that advertises no instance name. - Windows client: the `--discover` progress line. - KWin fake-input: the application name passed to `authenticate()` (the grant is cached per-exe, so the string is display-only). - THIRD-PARTY-NOTICES: fixed in both generators (about.hbs and gen-third-party-notices.py) and applied to the three checked-in outputs so they match what a regeneration now produces. Every changed line differs from the original only by letter case, so line lengths are unchanged and no formatter width rule is affected. `cargo fmt --all --check` passes.	2026-08-06 23:10:25 +02:00
enricobuehler	185a69c806	fix(web/plugins): a plugin's interface loads again, instead of an empty panel ... Two separate things had to be wrong for this, and both were. The frame's own policy locked it out. Plugin UIs moved to their own origin so a plugin cannot act as the logged-in operator, and the plugin origin names the console as the only page allowed to frame it. It built that name from the incoming request — but Nitro hands the app a synthetic request with no TLS socket, so an HTTPS console reads back as `http:`. The header said `frame-ancestors http://host:47992` while the operator was on `https://host:47992`, and the browser refused the frame outright (ERR_BLOCKED_BY_RESPONSE). Nothing on screen said so; the reason was only in devtools. The scheme now comes from the listener's own TLS state, stamped at bind time, with x-forwarded-proto winning when something in front terminated TLS for us — the one case where the browser's scheme is not ours. And the port was shut. 47993 was added to the firewall definitions, but an already-open firewall does not pick a new port up: ufw expands an app profile into rules when you allow it and keeps those, so editing the profile on upgrade changes nothing, and firewalld needs a reload. Every upgraded Linux host kept a 47992-only rule, silently. The packages now notice on upgrade and print the one command that fixes it, without touching the running firewall. The NixOS module and the container image never learned the port at all; both now open it. Also: the console no longer mounts the frame while it is still checking whether that origin is reachable. A firewalled port drops rather than refuses, so the check hangs for the browser's whole connect timeout, and mounting meanwhile is exactly the empty panel with no explanation. The card that follows now names both causes it can be — an untrusted certificate for that port, or a closed one — because from a browser the two are indistinguishable. The rule is now a pure function with tests, since its failure mode is a well-formed header that only a browser rejects. Verified on glass against home-worker-5 (.21) and its ROM Manager plugin: the frame was refused before, renders the plugin's UI after.	2026-08-06 22:33:57 +02:00
enricobuehler	8e02f3a8e1	Merge pull request 'ci(nix): a stale bun.nix can no longer reach main unnoticed' (#73) from worktree-nix-bun2nix-drift-gate into main ... Reviewed-on: #73	2026-08-06 14:46:25 +00:00
enricobuehler	fb707b4956	ci(nix): a stale bun.nix can no longer reach main unnoticed ... Moving the bun packages to bun2nix (1db8f763) removed the aggregate deps hash that used to go stale, but not the second, quieter way a generated file rots. bun2nix is a pure function of bun.lock, and `bun.nix` is committed alongside it — but it regenerates ONLY from a local `bun install` that runs lifecycle scripts. It does not regenerate under `bun install --ignore-scripts`, which is what every bun install in CI uses, and it cannot regenerate on a merge or rebase, where git carries someone else's lockfile change past a `bun.nix` generated before it and reports no conflict. That is not theoretical. web/bun.nix went onto main holding brace-expansion@5.0.7 (plus two nested entries the `^5.0.8` override had already collapsed) while web/bun.lock said 5.0.8: the override landed in ec9aa415, the bun2nix branch had generated bun.nix off the pre-override lock, and the merge kept both. The Nix build fetches node_modules strictly from bun.nix, so the derivation's offline `bun install` was asked for a tarball its store cache did not contain and `nix build .#punktfunk-web` failed. It stayed broken for 553 commits (2026-07-27 -> 2026-08-05) and was closed by accident, when an unrelated advisory bump in b79d90b4 happened to rerun a real `bun install`. Nothing caught it because nothing could: the string "nix" appeared in exactly one workflow file, and only in a comment about bun2nix breaking a Windows step. * scripts/ci/check-bun-nix.sh regenerates each bun.nix from its committed bun.lock and diffs, with `--fix` to rewrite them. It reads which packages to check out of packages.nix's own `bunNix = src + ...` lines rather than a hardcoded list, so a third bun package is covered the day it is added, and an empty list is a hard error — a gate that checks nothing passes exactly like a clean tree. It also enforces the bun2nix version pin that flake.nix and the README only stated: bun.nix has no schema stability across releases, so the flake input ref and both package.json devDependencies must agree, and generation always uses the pinned version rather than a floating `bunx`. * ci.yml gains a `bun-nix` job running it. Deliberately unfiltered and not in nix.yml: it needs no Nix, takes under a minute, and the whole point is that this drift arrives through commits that look unrelated to Nix. * nix.yml is new and is the first CI that evaluates the flake at all — `nix flake check --no-build` over every output, then a real build of punktfunk-web + punktfunk-scripting, which are the two derivations whose inputs churn and the only ones that do not compile Rust. That leg is the end-to-end proof the drift gate cannot give: it catches a tarball the registry no longer serves, or the codegen going quietly message-less. It is path-filtered, has a workflow_dispatch opt-in for the hour-long Rust packages, and keeps `pull_request` — flatpak.yml shipped push-only and let manifest breakage reach main invisibly for weeks. The script is POSIX sh (shellcheck-clean, exercised under dash, which is the CI container's /bin/sh) and avoids process substitution, the parse-time failure that silently disabled ci.yml's shader SPIR-V gate for 35 commits.	2026-08-06 15:28:14 +02:00
enricobuehler	79ee308a7a	build(rpm): declare all seven FFmpeg pkg-config modules, not three ... `ffmpeg-next` is pulled with default features, so `ffmpeg-sys-next`'s build script pkg-config-probes codec/device/filter/format/util/resampling/scaling and panics on the first one missing. The spec named three. RPM Fusion's `ffmpeg-devel` ships all seven in one package, which hid it. On a host where those three instead resolve to Fedora's split `libav*-free-devel` packages, `dnf builddep` installs exactly three and the build dies in a build script: The system library `libavfilter` required by crate `ffmpeg-sys-next` was not found.	2026-08-06 15:03:05 +02:00
enricobuehler	25b08916b6	fix(flatpak): the WSI layer module builds again — vkroots was declared twice ... The flatpak has not built since 35ba64ca. Every push to main fails at "Build the flatpak", before a single build command runs: cp: cannot overwrite non-directory '.../build/gamescope-wsi-layer-1/subprojects/vkroots/.git' with directory '.../git/https_github.com_Joshua-Ashton_vkroots.git' Error: module gamescope-wsi-layer: Child process exited with code 1 vkroots was declared twice. flatpak-builder clones git sources WITH SUBMODULES by default, and `subprojects/vkroots` is a real gamescope submodule — `git ls-tree 8c676c39 subprojects/` shows it as mode 160000 at 5106d8a0, which is byte-for-byte the commit the explicit source pinned. So the submodule checkout already produced the right tree and left `subprojects/vkroots/.git` as a gitlink FILE; the second, redundant source then tried to copy the bare mirror onto that path as a DIRECTORY, and cp refused. Source extraction died there — `buildsystem: simple` and the hand-applied glm/stb patch_directory copies were never reached, so neither is at fault. Removing the redundant source is therefore a no-op on the resulting tree: the submodule supplies that exact rev. glm and stb are NOT submodules — `subprojects/ glm.wrap` and `stb.wrap` are plain blobs at that rev — so nothing else populates them and their explicit sources have to stay. That asymmetry is the whole trap, and it is now written down in the manifest next to the sources, along with the disable-submodules escape hatch for anyone who later needs to pin a subproject away from the gamescope rev. Why this reached main: flatpak.yml has no `pull_request:` trigger — only `push` on main with path filters, `tags: ['v*']`, and workflow_dispatch. PR #64's checks were green because the flatpak was never built on the PR; run 15775 was the first time this module had ever been built in CI. Adding a PR trigger (or a manifest lint) is the durable follow-up, deliberately not bundled here. This blocks the release, not just main. flatpak.yml runs on `tags: ['v*']`, and the failing step gates the bundle export, the generic-registry publish, the OSTree push to flatpak.unom.io and the release-asset attach — all of which stay skipped. A v0.25.0 tag cut today would ship with NO Linux/Steam Deck flatpak at all, on the release whose headline Linux change is Deck HDR working out of the box. NOT VALIDATED LOCALLY: this cannot be built on macOS. The reasoning is confirmed against the upstream tree (the ls-tree above) but the green run is still owed — dispatch flatpak.yml on this branch before merging.	2026-08-06 00:49:25 +02:00
enricobuehler	5f71aeb024	feat(flatpak): vendor the gamescope WSI layer so Deck HDR works on a plain install ... HDR on a Deck needed a manual second step nobody took: flatpak install --user flathub org.freedesktop.Platform.VulkanLayer.gamescope//25.08 documented only in a comment in this file. Build the layer ourselves instead, so a plain `flatpak install` is all it takes. The layer is genuinely required, not legacy. Measured on SteamOS 3.8.16 (gamescope 3.16.23.4): the gamescope-0 socket advertises gamescope_swapchain_factory_v2 but NOT wp_color_manager_v1, with HDR both off and on — so Mesa's Wayland WSI has no colour-management protocol to negotiate HDR10 through, and this layer is the only thing that can append the ST.2084 surface formats. Removing the extension gives zero [Gamescope WSI] lines and hdr10_format=None. Vendored rather than declared via add-extensions autodownload: the extension is 94 MB of whole-gamescope for one 4 MB .so, its layer JSON hardcodes a /usr library_path that an app-scoped extension mounted under /app would not satisfy, and it would make flathub a hard install-time dependency of an app we self-host on flatpak.unom.io. enable_gamescope=false skips subdir('src') and every compositor dependency, so only protocol/ and layer/ build. buildsystem is simple rather than meson because glm and stb ship no meson.build of their own - the wraps' patch_directory supplies it, and without that copy configure dies with "Subproject exists but has no meson.build file". meson generates the layer JSON from prefix+libdir, so it self-writes library_path=/app/lib/... into /app/share/vulkan/implicit_layer.d, which XDG_DATA_DIRS already covers. VK_ADD_IMPLICIT_LAYER_PATH is therefore dropped - keeping it would also risk double-loading two same-named layers for anyone who still has the flathub extension installed. Pinned to the same gamescope rev as packaging/gamescope/PKGBUILD so the client's layer and the host's punktfunk-gamescope come from one tree. Verified on a Deck OLED: builds offline (--wrap-mode=nodownload) in org.gnome.Sdk//50, and the resulting .so drives the Deck's system gamescope to "hdr formats exposed to client: true" with hdr10_format=Some(A2B10G10R10_UNORM_PACK32, HDR10_ST2084_EXT). Still user-side, and not fixable in packaging: gamescope's hdr_enabled convar (Steam's HDR display setting) must be on.	2026-08-06 00:15:16 +02:00
enricobuehler	e1adc5d6d7	fix(flatpak): export GAMESCOPE_WAYLAND_DISPLAY so the Deck actually gets HDR ... The gamescope WSI layer decides whether to engage from one signal: isRunningUnderGamescope() reads $GAMESCOPE_WAYLAND_DISPLAY and nothing else. flatpak does not forward host env into the sandbox, so it arrived unset and the layer's CreateInstance early-returned before creating a GamescopeInstance — no gamescope surface, so the HDR10/ST.2084 formats were never appended and the surface stayed SDR. The layer still loads and still logs its generic bits in that state, so it reads as working. It is not: the three settings already here (layer search path, ENABLE_GAMESCOPE_WSI, the socket bind) all sit downstream of this gate and buy nothing without it. Measured on a Deck OLED (Galileo, SteamOS 3.8.16), client --browse, reading "swapchain config": unset -> no [Gamescope WSI] Surface state block, None set, hdr_enabled=0 -> server hdr output enabled: false, None set, hdr_enabled=1 -> hdr formats exposed to client: true, Some(A2B10G10R10_UNORM_PACK32, HDR10_ST2084_EXT) Matches the field report of "HDR->SDR" in the stats overlay on a correct HDR host. DXVK_HDR was ruled out by measurement. The remaining gate (gamescope's hdr_enabled convar = Steam's HDR display setting) is a user-side step, not a packaging one.	2026-08-05 23:59:45 +02:00
enricobuehler	d2085879da	Merge main: plugin art rides THROUGH the H-2 confinement, not around it ... PR #58 hardened the art proxy in the same three files this branch rewrote, and the two changes pull in opposite directions: #58 narrowed what the host will read from disk, while WP1.2 widened what counts as a local art path so an extracted scanner's covers can be served at all. Resolved so the widening goes through the gate rather than beside it. Kept from #58, unchanged: art_path_is_confined (UNC refusal, canonicalize-or- refuse, config-dir exclusion, roots check), the image-extension whitelist, sniff_image_type, validate_art_paths as write-time validation, the AuthLane privileged-field check on every entry in a reconcile payload, and the launch redaction in GET /library. Three reconciliations: * `local_art_bytes` converts a `file://` value to a path BEFORE calling art_path_is_servable, so the confinement check and the read see the same path. Ordering is the point: percent-decoding happens before canonicalization, so a `%2e%2e` escape cannot hide from the traversal check. Pinned by a test. * `art_roots()` gains $HOME on POSIX. This is the one that would have bitten silently: the list was empty on non-Windows, which was correct while is_local_art_path was Windows-shaped (Playnite is Windows-only, so nothing on a POSIX host was ever classified as local art and the confinement had nothing to confine). Once WP1.2 classifies POSIX paths as local, an empty root list is not "secure by default" — it serves NO plugin art on Linux, which is every cover the lutris and steam plugins emit. $HOME is the exact analogue of the Windows users base #58 already ships, and covers Steam's librarycache and grid overrides, Lutris's coverart/banners (both copies), Heroic's caches and all the Flatpak variants. It is not the load-bearing control: a value still needs an image extension, must canonicalize to a real regular file inside a root and outside the config dir, and must CONTAIN image bytes. * The two tests that both wanted to mutate PUNKTFUNK_LIBRARY_ART_ROOTS became one. Cargo runs tests as parallel threads of a single process, so two tests setting the same env var race. The `file://` and confinement assertions moved into #58's existing confined test; what remains of the WP1.2 test is the pure classification/rewrite half, which touches neither env nor filesystem. Also: `steam_ui` was missing from the list of host-resolved launch kinds in privileged_field's doc comment and in the 403 a plugin sees. Prose only — the check is a denylist (prep, launch.kind = "command"), so steam_ui was never actually refused — but a plugin author reading that error would have concluded otherwise. Gates on .21: punktfunk-host 433 passed / 0 failed (including #58's H-2 tests and the new file:// ones), full workspace tests clean, workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift test green.	2026-08-05 19:59:11 +02:00
enricobuehler	defdfbdb58	fix(security): plugin UIs get their own origin ... Closes H-3 of the 2026-08-05 review, the last of its six highs. A plugin's interface was reverse-proxied onto the console's own origin and framed with `allow-same-origin`, so plugin JS ran as first-party code on that origin: one `fetch('/api/**', {credentials:'same-origin'})` and the BFF attached the operator's ADMIN bearer. That reached everything `plugin_may_access` withholds — arm pairing, read the host PIN, approve a device, read `/hooks`. The "open in new tab" link was the same escalation with no iframe involved at all. The fix is not a sandbox attribute, and it is worth writing down why, because the obvious change is the one that does not work. Dropping `allow-same-origin` gives the frame an OPAQUE origin; its subresource requests are then cross-site; the `SameSite=Lax` session cookie stops being sent; every plugin asset 302s to /login and the frame is blank. Nothing about the new-tab link is helped either. So the origin moves instead. A second listener on its own port (default PORT + 1) serves plugin UIs and nothing else: different ORIGIN — scheme+host+PORT — so the same-origin policy separates the plugin from the console: it cannot read the console's DOM, its cross-origin fetch of /api/** is unreadable (no CORS) and cannot mutate (Sec-Fetch-Site sees same-site). same SITE — cookie scope ignores the port and SameSite is computed on the site, so the session cookie still reaches the plugin listener and plugin pages keep working. Enforcement is two refusals and both are load-bearing: the console origin refuses /plugin-ui/**, and the plugin origin refuses everything ELSE — above all /api/**, which would otherwise hand the admin bearer right back to plugin JS that is now same-origin with that listener. Both are unconditional: if the plugin port cannot be bound, plugin UIs are DISABLED and the console says so, rather than falling back to the arrangement this exists to remove. Two consequences that would otherwise bite in the field: The port has to be open. Done for the Windows netsh rule, the firewalld service and the ufw profile. A browser stores a self-signed-certificate exception per ORIGIN, including the port — and a certificate interstitial can never be shown inside an iframe, so the frame would just sit blank with nothing on screen explaining why. A `no-cors` probe distinguishes it (a TLS failure rejects; any HTTP answer, even 401, resolves) and the console renders a card linking the operator to open the port once in a real tab. Also here: the health probe moved server-side to the console origin (it used to rely on being same-origin with the plugin), the postMessage listener now verifies `event.origin` — a real check rather than a tautology — and plugin-kit's `postMessage(..., "*")` is documented as load-bearing, since narrowing it to `location.origin` would now target the plugin's own origin and silently drop every message. Verified against a running console with a fake mgmt API and a fake plugin: console /plugin-ui/** → 404; plugin-origin /api/v1/hooks, /, /login, /_auth/logout → 404; plugin page loads 200 through its own origin; unauthenticated plugin origin → 401 (not a redirect to a /login it does not serve); a forged x-pf-listener header changes nothing on either listener; the plugin's own Clear-Site-Data / Access-Control-Allow-Origin / Set-Cookie are dropped by the proxy allowlist; the plugin origin's CSP names the console as its only frame-ancestors source; and with the port squatted, ui-config reports `unavailable`, the console still refuses /plugin-ui/**, and the console itself keeps working. Still wants on-glass confirmation in a real browser — the cookie and framing behaviour is reasoned from spec, not observed. cargo fmt --all --check clean; cargo check -p punktfunk-host --all-targets green on Windows; web console builds and typechecks.	2026-08-05 17:50:04 +02:00
enricobuehler	8103958169	fix(security): the plugin lane stops being a way in ... Acts on the 2026-08-05 host security review. 36 of its 38 findings; the two exceptions are recorded below and in the review doc. The review's headline is that `plugin_may_access` was the one authorization gate in the system that was allow-by-default — a hand-maintained denylist of route prefixes, where every sibling gate is deny-by-default. Its own doc comment names the two capabilities it exists to withhold, and both were reachable one route over, because ~1450 commits of new routes were added and the list was never one of the things anyone remembered to update. So the gate is now an allowlist, and a test walks the live route table and fails the build for any route that has not been deliberately classified for both non-admin lanes. That test is the actual fix: it is what stops the next route from arriving pre-authorized. Route reachability and field authority turned out to be different questions. A provider plugin has to be able to reconcile its own library entries — that is what a scanner plugin IS — but `prep` and a `command` launch inside that payload are handed to `/bin/sh -c` as the host user, and every execution site documents them as operator-typed. Requests now carry the lane that authorized them, and those two fields are refused to everyone but the operator's own token. The art proxy read any absolute path off disk in the host process, which on Windows is LocalSystem, from a path the plugin lane could write and then read back — so it yielded `mgmt-token`, which is full admin. It now serves only real images (extension AND magic bytes, so a renamed secret fails), only from inside an allowed root, only after canonicalization, and never over UNC; and a path it would refuse to serve can no longer be persisted in the first place. On Windows, the config-dir hardening was skipped exactly when it was needed — it ran only in the branch that CREATES host.env, so the case it was written for (a local user pre-created the directory and planted one) was the one case it never ran in. It is now unconditional and first, an existing host.env is re-owned, and the inheritable OWNER RIGHTS ACE that kept an attacker's files theirs after the directory was re-owned is gone. The identity and token readers were hardening the directory only on the path that GENERATED a new secret, so a planted cert/key or token was adopted verbatim and permanently; they harden before the first read now. `ensure_admin_only_source` is implemented. The 2026-07-05 audit recorded it as FIXED and it was in no commit in this repository's history — the local EoP it described was live, and it is the payload half of the config-dir chain above. Also: the three input planes are bounded and lossy like the mic plane on the same loop already was; Android's library client no longer accepts any publicly-trusted certificate for the pinned host; the usbip vhci nodes get their own group instead of riding on `input`, which every packaging scriptlet tells users to join; a registry URL can no longer inject a TOML table into bunfig.toml; the pairing cooldown is charged before the arming state is read, so armed/disarmed is no longer a free oracle; and the whole Low tier, of which the two worth naming are a clipboard MIME NUL that panicked the host on one control message, and an unauthenticated global logout that let any LAN peer sign the operator out on a loop. NOT fixed, deliberately: H-3 (plugin UIs framed allow-same-origin). Dropping allow-same-origin does not work: the document's origin goes opaque, its subresource requests are then cross-site, the SameSite=Lax session cookie is not sent, and every plugin asset 302s to /login. The "open in new tab" link is the same escalation with no iframe at all, so the sandbox attribute is not where this gets fixed either. It needs a second listener — a distinct origin that is still the same site — which changes the console's deploy model and wants on-glass validation. The mechanism and the dead end are written down at the iframe. H-6 registry authentication, whose other half lives in unom/infra. The in-repo halves are done: workflow_dispatch inputs no longer interpolate into run: blocks (one of them in the step holding UPDATE_MANIFEST_KEY), and the syft installer is pinned to its tag instead of main. Digest pinning is left until the registry is authenticated, because a tag — content-keyed or not — can simply be overwritten while anonymous pushes are accepted. M-5 is half done: the oracle is closed, but binding the arming window needs the console to learn the fingerprint first, which is a knock-then-bind flow rather than an edit. Verified: cargo fmt --all --check clean; cargo check --all-targets green on Linux and on Windows (confirmed non-vacuous — a planted type error in windows/install.rs fails the build); scripts/xcheck.sh windows check green; cargo test -p punktfunk-host --bins 416 passed, the single failure being gamestream::stream::tests::sender_delivers_batches, the known qemu-environmental UDP-loopback flake that fails identically on clean main in the same container; cargo test -p pf-clipboard 13 passed; web console typechecks.	2026-08-05 17:12:12 +02:00
enricobuehler	ce8f3e9eaf	feat(packaging): the plugin runner becomes a default component ... WP6.1 of design/library-scanner-plugins-implementation-plan.md. The library is a flagship surface and cannot depend on an opt-in subsystem (design D9, closing G9): once the scanners are plugins, a host whose runner is off comes up with an empty library and no obvious reason why. The security posture for on-by-default was already built and shipped — LocalService on Windows, a sandboxed systemd --user unit on Linux, the scoped plugin-token lane. Windows (.iss): the PunktfunkScripting task is registered ENABLED and started on a FRESH install, and left to the existing restore path on an upgrade. The distinction is a new TaskExists probe taken before StopBunRuntimes disables anything — TaskEnabled alone cannot tell a fresh install from an operator who deliberately turned the runner off, and defaulting to "on" would silently switch it back on for them. deb/rpm: `systemctl --global enable` from the postinst/%post, guarded to first install only so an upgrade never undoes a mask. `--global` because a maintainer script has no user session to act on, and it is the only mechanism that makes a --user unit on-by-default for everyone. sysext: RPM scriptlets never run from a sysext image, so the enablement symlink is baked in directly (/usr/lib/systemd/user/default.target.wants/). Without it the runner would ship present-but-off on exactly the platform where an operator is least likely to go looking for it. Opt-out throughout is `systemctl --user mask punktfunk-scripting` — `mask`, not `disable`, since a plain disable cannot remove a symlink under /etc or /usr. The unit comment, both package descriptions, and the docs-site plugins page all say so; the page also gains the Windows equivalent. Not gated on hardware: none of this is verifiable from a Mac. The .iss change needs an installer run (fresh + upgrade, and an upgrade with the task deliberately disabled), and the deb/rpm/sysext changes need a package build.	2026-08-05 10:08:11 +02:00
enricobuehler	31b5f90b12	fix(host/windows): two virtual pads stop tearing each other's reports ... Three faults on the Windows pad path, two of them races that only bite when a game drives a pad hard enough for two callbacks to overlap. pf-gamepad's output ring could hand the host a torn report. Publishing is a read-modify-write — read the cursor, write the slot it names, advance it — and the framework dispatches output callbacks in parallel, so two could be inside it at once: both read the same head, both wrote the SAME slot, and both stored head+1, so the cursor moved once for two reports and the host read a single entry with two reports mixed into it. An atomic fetch_add does not fix this. It hands each writer its own slot but advances the cursor before the bytes exist, so the host is then invited to read a slot still being filled. Serializing the publish is what makes the cursor bump mean "the slot below is complete". The ring exists to stop a rumble STOP being coalesced away, and a torn slot can eat that STOP with no idle watchdog behind it. Both drivers also promised the host an ordering they never established. The host loads out_seq and rumble_seq with Acquire and says so in its own comments — "Acquire pairs with the driver's publish-then-bump store order" — but the drivers bumped both with plain writes, and an Acquire load pairs with a Release store and nothing else. On a weakly-ordered core the host could see a fresh seq against stale bytes. pf-xusb's rumble seq was racy in the same way as the ring: two SET_STATE calls could both read one value and both write back value+1, so the host saw one bump for two writes and skipped a level. A skipped stop is the one that hurts — the pad buzzes until the ~2.5 s idle force-off notices the game went quiet, which is what bounds the damage. Diagnosing an unattached driver stalled the session. The pad service thread — the one feeding input and rumble — waited up to two seconds for a pnputil enumeration, per unattached pad, at exactly the moment a session was already going wrong. The diagnosis now runs on its own thread. Off the hot path the wait no longer has to be a compromise, so it is generous enough to report what it actually found instead of giving up with "still enumerating" — which, given pnputil routinely takes longer than the old budget, is what it usually did.	2026-08-04 19:20:01 +02:00
enricobuehlerandClaude Opus 5	e726542f96	docs(winget): the vhost belongs in unom/infra, not on the box ... Step 2 told you to add the Caddy vhost by hand on unom-1. That instruction is what broke the source: ~/caddy/Caddyfile is a copy that deploy-all.sh rsyncs over from unom/infra, with no .git there to warn you, so the hand-added block survived until the 2026-07-31 hardening commit rewrote the file from the repo's own copy and deleted it. Point step 2 at unom/infra and record how the failure presents, since it does not look like an ingress problem from the client side: no vhost means no certificate for that SNI, so Caddy answers with TLS internal_error (alert 80) before sending one, and winget surfaces that as WINHTTP_CALLBACK_STATUS_FLAG_SECURITY_CHANNEL_ERROR / 0x8a15003b. Also note that port 80 is useless for diagnosing it — Caddy 308s every Host to https including names it has never heard of — and give the SNI probe that does work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 10:43:39 +02:00
enricobuehlerandClaude Fable 5	02a5bdb965	fix(gamepad): the virtual DualSense stops demanding a firmware update it cannot take ... The emulated pad's firmware-info feature report (0x20) advertised update version 0x0154 — a 2021-era number. PlayStation Accessories compares it against Sony's latest (0x0630 as of 2026-08) and offers an Update that can only end in "can't complete the update", since the virtual pad speaks no DFU; libScePad titles (Stellar Blade) surface the same nag in-game. A real pad plugged in directly reads up to date, which made the prompt look like punktfunk corrupting the controller. The old value was chosen to keep the kernel and SDL on the flag0 COMPATIBLE_VIBRATION convention, but parse_ds_output has since learned the firmware-≥2.24 COMPATIBLE_VIBRATION2 flag as well, so nothing depends on looking old anymore. Advertise 0x0999 — above anything Sony has shipped and comfortably ahead of their ~yearly cadence — instead of chasing their exact latest, which would resurrect the prompt on every Sony release. Writers that read the version now use the v2 flag; both conventions land in the same rumble plane. Bumped in both copies of the blob (host uhid + Windows driver); the DualSense Edge shares them, and its own versioning (0x0217 latest) sits below the new value too. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 10:24:20 +02:00
enricobuehlerandClaude Fable 5	5926306a4c	feat(windows): the web console becomes a supervised child of the host service ... Three silent console outages in one week (0x1 / 0xFFFFFFFF / 0x41306), each a different proximate cause of the same structural defect: the console's lifecycle was owned by Task Scheduler — one best-effort start per boot/logon/install, no retry on a plain non-zero exit, no watchdog — while the product already shipped a real supervisor. The service now supervises the console as a second child slot: plain session-0 spawn (suspended → own no-breakaway kill-on-close job → resume), started only once the host has written mgmt-token + cert.pem + key.pem (the cert race dies by construction), secrets read from their files at every respawn, bun's stdout finally captured in logs\web.log, doubling backoff 0.5s→60s that never gives up. Session switches never touch it; a service stop takes it down via the job. The PunktfunkWeb task is retired: web setup slims to password + legacy task delete + firewall, the 127-line web-run.cmd batch supervisor is deleted, an [InstallDelete] entry reaps the stale copy, and service install now sets SCM crash-recovery actions (restart 1s/5s/60s) since the console rides on the service process. StopBunRuntimes stays for the scripting runner + the one migrating upgrade. Design: punktfunk-planning design/windows-web-console-lifecycle.md Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 20:16:19 +02:00
enricobuehlerandClaude Opus 5	020306b5ac	fix(packaging,host): a fresh Linux install can start, and the comments stop lying ... Fallout from the documentation sweep: verifying doc claims against the code turned up defects in the code and the shipped templates. Mostly comments that describe behaviour we no longer have — which is how the docs went wrong in the first place, since someone reads the comment and writes the page. The one that mattered: a fresh deb/RPM/Arch install could not start the host at all. The unit's `EnvironmentFile=` had no `-`, making host.env mandatory, and no package creates it — all three ship only the templates under /usr/share and the postinst merely prints the copy command. So `systemctl --user enable --now punktfunk-host` died on "Failed to load environment files". Every field in HostConfig::from_env resolves through unwrap_or/filter/None, so absent means all defaults, exactly like a hand-run `serve`; the Nix module already wrote it as `-${environmentFile}`. The Deck installer's own generated unit gets the same prefix for the case where an operator later removes the file. Shipped templates: PUNKTFUNK_SECURE_DDA is read by nothing (DDA/WGC are gone; IDD-push is the sole Windows capture path and the secure desktop is unconditional), so it stops being written into a fresh host.env; PUNKTFUNK_INPUT_BACKEND offered a `uinput` value that does not exist and omitted `kwin`, which is what a KDE session actually resolves to; PUNKTFUNK_RENDER_ADAPTER no longer claims to pick a "Desktop-Duplication" GPU. Comments corrected rather than deleted, since each explains a real why: PUNKTFUNK_10BIT is default-on with explicit-off grammar, not an operator opt-in; GNOME reaches EIS through Mutter's direct RemoteDesktop API, so it needs no portal approval and is headless-capable; and the host does not run in session 0 — the service is the session-0 supervisor and the host runs as SYSTEM in the interactive console session, which is why game_term has to bind the input desktop at all. packaging/bazzite/update-punktfunk.sh is now installed to /usr/share/punktfunk/, so the command the docs promised exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 18:46:38 +02:00
enricobuehlerandClaude Fable 5	19392918ff	feat(gamescope/hdr): HDR is attempted by default and every install path ships the patched gamescope ... Field report (RX 5700 / SteamOS): 10-bit HEVC "unsupported" — but the GPU was never the blocker (RADV probed Main10 fine on that box). The session stayed SDR because stock gamescope offers no 10-bit PQ capture formats and nothing shipped our pipewire-hdr build outside the Bazzite sysext, while PUNKTFUNK_GAMESCOPE_HDR additionally defaulted off everywhere. Close all three gaps: - PUNKTFUNK_GAMESCOPE_HDR now defaults ON (explicit-off grammar, the flip the config comment planned post-canary). Safe by construction: the +pfhdr banner probe, managed-spawn term, and client 10-bit cap keep stock-gamescope boxes on the exact 8-bit path. The nix module's gamescopeHdr (default true now) only controls whether the patched binary is on PATH; it no longer sets the env. - SteamOS: new scripts/steamdeck/build-gamescope.sh builds the HDR gamescope in the same pf2 trixie distrobox (apt dep list validated by a full build in a debian:trixie container), installs ~/.local/bin/punktfunk-gamescope, and maintains PUNKTFUNK_GAMESCOPE_BIN in host.env ONLY while the binary passes its on-glass --version/+pfhdr check — a stale absolute override would break session spawning, not just HDR. Wired into install.sh (§3b), update.sh (retrofit), and rebuild-check.sh (ldd-probes it like the host binary). - Arch: build-sysext.sh gains a --gamescope fold-in (banner-verified by execution, host-image-only), and punktfunk-host optdepends the companion. Deliberately NO CI-published host sysext: per the 2026-07-22 packaging verdict a prebuilt SteamOS host breaks on A/B soname bumps (and /var is per-partition-set), so arch.yml records that instead — SteamOS hosts use the distrobox flow above. Also fixes a latent bug that made build-sysext.sh fail every invocation as documented: a literal `}` inside `${1:?usage …{host,client}…}` terminates the expansion early and corrupts $PKG (caught by the new synthetic-package test, which also covers the fold-in, the unmarked-gamescope refusal, and the client-image guard). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 13:50:31 +02:00
3 people	b164b4c03e	feat(packaging): a client-only box can update its client without the host ... The root helper, its unit, the group-scoped polkit rule and the install-kind marker all shipped with the HOST package. A Steam Deck or a handheld has no host package, so the client half of one-tap updates had nothing to stand on. The client packages now ship their own copies — deliberately under their own paths (`pf-update-client`, `punktfunk-client-update.service`, `49-punktfunk-client-update.rules`, `/usr/share/punktfunk-client/install-kind`) rather than sharing the host's. Two packages owning one path is a hard conflict in dpkg, rpm and pacman alike, and the client marker needs its own DIRECTORY too because the host RPM claims `%{_datadir}/punktfunk/*` with a glob — a sibling file there would break `dnf install punktfunk punktfunk-client`. `pf-update` grows the matching `apply-client` verb. The verb comes from a root-owned unit's fixed ExecStart, never from the caller, so the zero-parameter invariant holds; both verbs sweep every installed punktfunk package, and what the verb selects is which marker is read and which binary the run-the-binary gate executes afterwards. A client sysext is refused with its reason: the signed feed carries the host image, and installing that over a client-only box is not an update. The opt-in group is created by both packages' scriptlets, idempotently, so whichever lands first wins. Also fixes the host's own helper install: it read `$R/target/release/pf-update`, which is the source checkout, while build() exports CARGO_TARGET_DIR="$srcdir/ target" and every other binary in the file installs from `$T`. Both now read `$T`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 09:41:26 +02:00
enricobuehlerandClaude Fable 5	15361b0091	fix(drivers/gamepad): drop the 1 s enumeration wait its own premise doomed, and gate the logger ... The PnP-identity fix established that the sealed channel is STRUCTURALLY unavailable while hidclass enumerates (the DATA section arrives over the HID interface those very queries create) — so device_type()'s bounded 1 s pump loop, reachable only for a devnode whose hardware ids matched nothing, could never succeed there: it burned a second of a WUDFHost dispatch thread mid-enumeration and then fell back to LAST_DEVTYPE anyway. The fallback chain is now wait-free (attached section → PnP identity → LAST_DEVTYPE), and the 8 ms timer refreshes LAST_DEVTYPE whenever the section is attached, so the last resort is always current. The logger also joins its siblings behind file_log_enabled(): a RELEASE driver without the opt-in no longer OutputDebugStringA's (+ CString + format! allocs) per logged event — the rumble OUTPUT hex dumps and the cyclic GET_STRING polls were sustained paths. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 00:59:50 +02:00
enricobuehler	2748b84933	style(vdisplay/driver): rustfmt one line the audit bundle left unwrapped ... `5742ec95` landed `create_monitor`'s EDID call split across two lines where it now fits on one, so the drivers workspace fails `cargo fmt --all --check`. Whitespace only — separated from the gamepad work it happened to block.	2026-07-30 23:40:35 +02:00
enricobuehler	00c29f82f2	fix(gamepad/windows): a pad enumerates as the controller it IS, not always a DualSense ... A Steam Deck client streaming to a Windows host had a stuck stick and a stuck d-pad. The virtual pad was enumerating with the DualSense VID/PID **and the DualSense report descriptor**, so Windows parsed the 64-byte Deck frame as DualSense report 0x01: LX = report[1] = 0x00 (stick hard left), LY = report[2] = 0x09 (hard up), and a d-pad hat of 0 — which is UP, held forever. The driver picked its identity from `device_type` in the sealed section, but hidclass asks for the descriptors and attributes while it STARTS the device, and the section can only be delivered over the HID device interface — which does not exist until those queries are answered. The channel was structurally unavailable at the only moment it was needed, so `device_type()`'s bounded wait always timed out and every identity fell back to DualSense. Not a race: DualShock 4 and the Edge enumerated as DualSenses too (verified on .173 — both report 054C:0CE6 with a 64-byte DualSense input report, while their on-demand strings read correctly). The devnode's own hardware ids carry the identity and are readable at EvtDeviceAdd, before anything is asked, so resolve it there. The section stays authoritative once attached; the old wait survives only for a devnode whose ids match nothing. `hwid_devtype_table_matches_the_driver` pins the host's hwid → device_type mapping against the driver's table, including the ordering trap that `pf_dualsense` is a prefix of `pf_dualsenseedge`.	2026-07-30 23:40:35 +02:00
enricobuehlerandClaude Fable 5	5742ec9548	fix(vdisplay/driver): the audit bundle — one timing formula, honest EDID, scoped watchdog, lock-free drain, D0-resume re-init, knobbed RT priority ... One signing pass over the 2026-07-30 audit findings: - Timing math unified (D4): monitor-description and target modes now come from ONE IddSampleDriver-exact builder differing only in vSyncFreqDivider; the virtual-display-rs legacy formula (width-less pixel rate, deliberately fractional vSync) is gone. - EDID (D5): the preferred-timing DTD is built from the SESSION's mode when it fits the encoding (pf-driver-proto's tested builder; 1080p60 stays the fallback); the range-limits descriptor covers everything the driver can advertise (max clock 150 MHz → 2550 MHz, max-H +255 — the old limits were violated by the driver's own 1080p120 default); product code 0 → 1. Deliberately still no HDMI VSDB — documented in the module doc. - INF (D6): UmdfFileObjectPolicy=AllowNullAndUnknownFileObjects added (the sibling drivers all carry it); the dead DeviceGroupId (inert under ProcessSharingDisabled) dropped; the IddCx0102-vs- IddMinimumVersionRequired=10 pairing documented as deliberate — 0102 is the extension's registered identity, not a version request. - Watchdog lifecycle (D7): device cleanup now stops the host-liveness thread (it ran forever and its reap raced device teardown over the same monitor list). - Drain path off the mutex (D8): the per-frame has/take_frame_channel checks (≥60 locks/s per worker on the mutex the whole control plane, the mode DDIs and the watchdog contend) are gated by a delivery generation counter — the steady state takes no lock. - Adapter cache (D9): last-write-wins slot instead of a OnceLock, and a D0 re-entry from a REAL low-power state clears + re-inits — the stale pre-power-cycle handle used to wedge every later IOCTL_ADD. - Realtime GPU priority (D10): IddCxSetRealtimeGPUPriority is now A/B-able without a rebuild (PFVD_NO_RT_GPU, machine env) — no canonical IDD driver raises it, and it preempts the game's and DWM's queues at a level apps can't reach. - Logging (D2): the logger rides file_log_enabled() as a whole — a RELEASE driver without the opt-in no longer OutputDebugStringA's (+2 allocs) per logged event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:35:32 +02:00
enricobuehlerandClaude Fable 5	1c15ba89c3	fix(drivers/pads): the XInput path stops re-mapping the mailbox, and release logging gets a real off switch ... pf-xusb pumped the sealed-channel bootstrap mailbox — an open+map+close+ unmap plus two heap allocs — on EVERY XInput IOCTL, per pad. A periodic WDF timer (the pf-gamepad pattern) now owns the pump: adoption, re-delivery and host-gone detection happen there, and the IOCTL path reads the cached view. A vanished host still reads as a neutral pad within one 8 ms tick, and the heartbeat mark still advances per serviced IOCTL, so the host keeps seeing the GAME-visible polling path move. Both pad drivers' log() also called OutputDebugStringA unconditionally — a syscall + CString + format! alloc per logged event in RELEASE builds, on per-IOCTL paths (SET_STATE hex dumps during rumble, the cyclic GET_STRING polls). The whole logger now rides the existing file_log_enabled() gate (debug builds, or PF*_DEBUG_LOG), and dbglog! skips its format! too. (pf-gamepad's identical log shape is deliberately untouched: the unpushed fix/deck-hid-identity branch owns that file right now.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:35:32 +02:00
enricobuehlerandClaude Fable 5	e90c5d5bcd	fix(gamepad): the output-report ring absorbs haptics-rate writers (PadShm v2.2) ... A field log (2026-07-30) showed a game driving the virtual DualSense's output endpoint at >2 kHz sustained for tens of seconds. The 8-slot ring — sized on the assumption that 2 kHz is double any real HID output rate — overflowed every 4 ms poll, which force-silenced rumble for each storm's whole duration and flooded the log at ~230 WARN lines/s (96 % of the user's 5000-line web-console export, evicting the session history it was needed to diagnose). Three legs, negotiated so every old/new host×driver pairing keeps working: - pf-driver-proto: the ring grows in place 8 -> 56 slots; PadShm becomes exactly one page (4096 B), the hard ceiling that keeps cross-generation section views mappable. A new out_ring_len field carries the driver's side of the length negotiation. Deliberately NOT a GAMEPAD_PROTO_VERSION bump (that fails closed - no pad at all). - pf-gamepad driver: picks its ring length from the host's out_ring_ver stamp (>= 2 + a full-size map -> 56) and echoes it before every ring_head bump (now a Release store), so an Acquire-observing drain always reads the modulo that indexed the slots it copies. - host drain: follows the echo (0 = old driver = 8); on genuine overflow it now salvages the legacy latest-report slot - the freshest coalesced state - instead of total silence, and the per-poll overflow WARN is rate-limited to 1 line/s per pad with a suppressed count. Verified on the Windows CI runner (drivers workspace build + clippy -D warnings against the WDK; 64 pf-inject tests incl. the new negotiation/ salvage/limiter tests; pf-inject clippy -D warnings) and on Linux via the CI docker image (82 pf-inject tests). DriverVer needs no manual bump - the installer stamps a strictly-increasing build timestamp per release. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 18:36:47 +02:00
enricobuehlerandClaude Fable 5	06a249e49f	feat(host/linux): opt-in one-click updates — the pf-update root helper, group-scoped polkit grant, per-PM legs ... The U2 leg of planning:host-update-from-web-console.md. A new dep-free root helper (crates/pf-update) runs the distro package manager against the INSTALLED punktfunk packages — apt (index refresh scoped to our list when present), dnf, rpm-ostree (single-transaction re-resolve, reported staged), sysext (the proven signed-feed updater), pacman only behind the explicit PACMAN_FULL_SYSUPGRADE opt-in — then the run-the-binary gate, then a root-written result record. Zero attacker-influenceable parameters end to end: fixed ExecStart oneshot (punktfunk-update.service), polkit rule scoped to that one unit's start verb for the shipped-EMPTY punktfunk-update group (joining it is the auditable opt-in; every postinst creates it, none populate it). The host starts the unit, interprets the record (staged / nothing-newer-yet / changed), and crosses its own restart on the same intent/reconcile machinery as the Windows leg. Status now reports staged results and the opt-in hint. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 15:55:27 +02:00
enricobuehlerandClaude Fable 5	c64ada5649	fix(windows/installer): an update stops every bun before it replaces bun.exe ... Updating to 0.22.1 could die on a modal: "C:\Program Files\punktfunk\bun\ bun.exe — DeleteFile failed; code 5. Access denied." Windows will not delete a running executable, so that message means a bun was still alive when the copy reached it, and the installer had no way to recover. Two things run that bun, and neither is a child of the host service, so stopping the service — which the installer does correctly wait for — never touched either. Both are Task Scheduler tasks: PunktfunkWeb (SYSTEM, the console) and PunktfunkScripting (LocalService, the plugin runner). The only pre-copy stop we had looked for exactly one of them, and found processes by task name or by who was listening on 47992/3000. The plugin runner matched neither clause: different task, and it listens on no port at all. So anyone who had run `plugins enable` held bun.exe mapped through the whole install and failed this way on every single update. The web console could lose the race too. Stop-ScheduledTask returns once termination has been *requested* and Stop-Process is TerminateProcess, so the old code went straight from asking to copying; the Rust twin of that routine has always ended with a deliberate one-second settle. And neither task was disabled for the duration, while both carry restart-on-failure (web ten times a minute apart, scripting 999) and the web task also has a logon trigger — so a force-kill invited a respawn into the middle of a copy that takes well over a minute at lzma2/max. StopBunRuntimes now disables both tasks before stopping them, kills any bun whose image lives under the install dir — by path, so a developer's own bun survives — keeps the old port sweep for pre-bun installs that ran node on 3000, and then waits until both are actually gone rather than assuming. bun.exe also gains restartreplace, so if some bun still escapes all of that, the file lands on the next restart instead of dead-ending the install. Disabling a task is not free, though: unlike a stopped one it does not come back at the next boot, so an install that aborts anywhere after that point would take the console down for good. Hence two restores — a [Run] entry for the normal flow, and DeinitializeSetup, which Inno calls even when the user cancels. Both re-enable only what was enabled before the copy, and enabling an enabled task does nothing, so the pair is idempotent. Putting things back also turned up a second bug worth naming: the scripting entry re-registers its task and then unconditionally disables it, which is right on a first install and has silently switched an operator's plugin runner off on every upgrade since. The restore runs after both re-registrations and honours the prior state, so a fresh install still leaves the opt-in runner off. The Pascal and the PowerShell were both compiled and run on the Windows CI runner (ISCC, plus the query halves of each command) — but the install path itself is not yet exercised on glass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 14:36:46 +02:00
enricobuehlerandClaude Fable 5	cc01562631	feat(host): update check — signed per-channel manifest, install-kind detection, /api/v1/update surface ... The U0 leg of planning:host-update-from-web-console.md: a signed update manifest (Ed25519, keys pinned in the binary via the plugin-store verify path, serial floor persisted against rollback, channel-bound, 45-day stale hint) fetched lazily behind GET /update/status + rate-limited POST /update/check, admin lane only (plugin lane whole-prefix denied, absent from the cert allowlist). Install kind + channel come from root-owned facts; deb/rpm/pacman builds now stamp /usr/share/punktfunk/install-kind. Emits update.available once per discovered version. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 14:34:46 +02:00
enricobuehlerandClaude Opus 5	553676282a	feat(windows): the brand reads Punktfunk on every device Windows shows ... Device Manager, the firewall list and the monitor name all said "punktfunk". The brand is Punktfunk. Renamed: the [Strings] blocks of all four driver INFs (device descriptions, install disks, provider, manufacturer), the `description` on every SwDeviceProfile the host creates, pf-mouse's HID manufacturer + product strings, pf-vdisplay's IddCx endpoint friendly + manufacturer names, the EDID 0xFC display-name descriptor — so Windows now shows `Generic Monitor (Punktfunk)` — and the netsh firewall rule names. The EDID edit is a single byte (0x70 -> 0x50) and needs no hand-patched checksum: Edid::generate_with already recomputes both block checksums after patching the serial. Deliberately left lowercase, because these are IDENTITIES rather than display names and renaming them would orphan installed state: * the SwDeviceCreate enumerator `w!("punktfunk")` — it IS the SWD\PUNKTFUNK\... path every pad instance id is built from * pf-paths' `join("punktfunk")` — C:\ProgramData\punktfunk * the CN=punktfunk-driver cert subject, which purge_driver_certs and both driver build scripts match by string * install.rs' `lo.contains("punktfunk virtual display")` probes, whose haystack is to_ascii_lowercase()d, so they already match the capitalised name Nothing is orphaned by the renames that DID happen either: netsh rule names, Get-NetFirewallRule -DisplayName and PowerShell's -match are all case-insensitive, so the firewall delete paths and reset-pf-vdisplay.ps1's -AdapterName / -GhostMatch defaults still reap what every release up to 0.22.1 created. Cosmetic, with two consequences worth knowing: it takes a driver rebuild + re-sign to appear at all, and an existing devnode keeps its cached FriendlyName until it is recreated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:30:46 +02:00
enricobuehlerandClaude Opus 5	53ff313046	fix(packaging/gamescope): the shipped compositor starts on SteamOS — a rolling-distro libstdc++ never followed it there ... `punktfunk-gamescope-3.16.25.pfhdr2-1` off the pacman repo cannot start on SteamOS 3.8.16: `/usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.35' not found`. The Arch container CI builds it in is on gcc 16.1.1; SteamOS ships libstdc++ 3.4.34 and moves when Valve says so. Nothing else about the binary was wrong — every other soname resolved on the box, and glibc was never close (it asks for 2.38 at most against SteamOS's 2.41) — so the one dynamic C++ runtime was the whole reason the gamescope backend's own most important platform got a package that dies at `--version`. The C++ runtime therefore goes static, for the same reason wlroots already does: this binary is built on a rolling distro and has to start on a frozen one. It is safe here because gamescope links no shared C++ library at all — its NEEDED list is all C, and glslang/SPIRV are build-time only — so no C++ ABI crosses a shared boundary. Cost is ~1 MB (5.9 → 7.1). The flags are appended to LDFLAGS rather than passed as `-Dcpp_link_args`, which would replace the value meson derives from the environment and silently drop makepkg's `-z relro`/`-z now`/`--as-needed`. A static runtime is invisible in a passing build and only surfaces as a binary that will not start somewhere else, so the build now asserts it: no `libstdc++` in NEEDED, which needs no version threshold to check and turns the regression back into a build failure. Verified by building in `archlinux:base-devel` — the environment arch.yml uses, gcc 16.1.1 and glibc 2.44, both far newer than the target — and running the result on SteamOS 3.8.16 with nothing supplied: banner `punktfunk-gamescope version 3.16.25-4-g6bbe157+pfhdr2`, no libstdc++ in NEEDED, max GLIBC_2.38, every soname resolving. The host's whole HDR gate chain then answers on SteamOS for the first time (780M / RADV PHOENIX): 10-bit PQ capture offered, cursor painted in-node, native-plane HDR and GameStream HDR capable both true once `PUNKTFUNK_GAMESCOPE_HDR` is on, false with the distro's gamescope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 01:23:35 +02:00
enricobuehlerandClaude Opus 5	1a18ae1fae	fix(packaging/bazzite): the feed publisher signed a redirect page, not the manifest ... Every Bazzite install on the stable channel has been refusing the feed: !! the feed's SHA256SUMS is NOT signed by packages@unom.io (AF245C506F4E4763). The client was right and the feed was wrong. The registry answers a file GET with a 303 See Other pointing at presigned object storage, and `curl -f` does not treat a 3xx as an error — so the publisher's two un-`-L`'d manifest reads "succeeded" holding the redirect's HTML body, `<a href="…">See Other</a>.`, and handed that to callers as the manifest. That broke both of them: * --seal signed the HTML page. Its presigned URL is regenerated per request and expires 300s later, so the published .asc covers bytes that exist nowhere and can never verify. Stable feeds only publish on a tag, so they are only ever sealed — f43 and f44 were re-broken at 19:54Z on 2026-07-29 by the seal step of a canary run, and every canary push re-broke them. f43-canary survived by accident: on the publish path the same polluted bytes get both signed and uploaded, so it is at least self-consistent. * the publish merge read took the page for the previous manifest, and `grep -v " $FNAME$"` kept it — so each publish prepended a stale redirect page and dropped every prior image line. f43 runs KEEP=0 (keep all) and holds exactly one line, with 0.20.0 and 0.19.2 still in the registry and no longer listed. This has been quietly eating feed history since long before signing existed; nobody noticed because the client's latest() only matches ^punktfunk-.*-x86-64\.raw$, so an HTML line is invisible to it. Both reads now go through one read_manifest that follows redirects AND keeps only well-formed "<sha256> <filename>" lines, so a manifest is never again whatever the transport happened to return. --seal re-publishes a manifest that normalizing changed, since the signature has to cover the bytes a client downloads — that is what repairs the live feeds — and refuses outright when a manifest lists no images, rather than sealing an empty feed that would read as "up to date" to `punktfunk-sysext update`. The publish path now logs its carry-over count; silence there is what let the history loss run for months. Verified end to end against a fake registry that 303s to a fresh URL per request, with a throwaway key and the real scripts: HEAD reproduces the injected page, the lost image line and the client's VERIFY-FAIL; the fix keeps both images and verifies; and the new --seal over the broken state normalizes the manifest and turns it back to VERIFY-OK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:09:23 +02:00
enricobuehlerandClaude Fable 5	b2168dae6a	feat(vdisplay): stall attribution v1 — the driver testifies which leg lost the frames ... Every IDD-push capture stall now carries a VERDICT instead of a hypothesis list. The shared ring header grows a v2 telemetry tail (drain-loop heartbeat QPC, last-acquire QPC, full-width offered counter) the driver stamps on every drain pass; the host samples it between fresh frames and attributes each stall: worker-stalled (our thread starved) / compose-silence (DWM composed nothing — the disturbance is below capture) / delivery-leg (frames existed, our publish/ring/consume lost them). The metronomic WARN prints the running tally, so one pasted log line settles the Branch-1/Branch-2 fork of the vdisplay-disturbance-immunity program per session, per box. Both directions stay version-safe: the tail is gated on the HOST-stamped header version (a v2 driver never writes past a v1 host's 64-byte layout — it maps the whole section instead of a fixed 88 bytes), and a v2 host reads a zero heartbeat as pre-telemetry driver, no verdict. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 23:44:35 +02:00
enricobuehlerandClaude Opus 5	75e4f00e50	Merge branch 'chore/windows-rerender-semantics' into main ... Windows 11 tray theming + per-connect device-name announcement, and the pairing approve button no longer escapes the canvas on portrait phones. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 23:27:36 +02:00
enricobuehlerandClaude Fable 5	a420855b5a	feat(tray): the Windows tray dresses for Windows 11 and announces connects ... The menu was a stock Win32 popup: light-mode on a dark taskbar, DPI-virtualized (blurry on every scaled laptop), no icons. Now the process opts into the system dark mode via the uxtheme ordinals (135/136 - the same undocumented calls Explorer/PowerToys/Notepad++ make; menus never got a documented opt-in, and there is no WinUI tray API to move to), a PerMonitorV2 manifest makes menu and icon crisp, the multi-size .ico serves the DPI-correct frame, and items carry Segoe Fluent glyph bitmaps - with the UAC shield on the elevated service actions, per Explorer's convention. Rounded corners come free on Windows 11. Everything degrades gracefully: missing ordinals mean the classic light menu, a missing icon font means no glyphs. New: a connect toast on the idle-to-streaming edge - title "<device> connected" (from the summary's new client_name), body the mode ("Streaming 2560x1440 @ 120 fps") - via NIF_INFO, which Windows 11 renders as a native toast. The tray tags itself with the AUMID unom.punktfunk.tray and the installer registers it under Classes\AppUserModelId (DisplayName "Punktfunk" + the brand icon), so the toast is attributed to Punktfunk with the logo. Unregistered dev runs degrade to generic attribution, older hosts to a nameless title; a tray started mid-session never fires a stale toast. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:32:50 +02:00
enricobuehlerandClaude Fable 5	395daa8e98	fix(packaging/rpm): the CLI's %files entry had wandered into %install ... bf981027 added the punktfunk CLI to the spec, but its `%{_bindir}/punktfunk` files entry landed one section too early — inside %install, where rpm's shell dutifully executed /usr/bin/punktfunk (which doesn't exist on a builder) and killed both rpm legs at %install ever since. Move it where it was headed: out of the script, into %files client — which was missing it, so the fixed %install would otherwise have died again on an unpackaged /usr/bin/punktfunk. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:30:07 +02:00
enricobuehlerandClaude Opus 5	90c84ef4bc	fix(packaging/deb): build the CLI the client .deb installs ... With the client crates compiling again, deb got as far as "Build .debs" and died on `install: No such file or directory` — a confusing way to report that punktfunk-cli was never built. Two halves of the same omission, from when the `punktfunk` CLI was added. deb.yml pre-builds `-p punktfunk-client-linux -p punktfunk-client-session` and stops there, while build-client-deb.sh installs THREE binaries. Its build-if-missing guard tested only the first two, so the pre-built pair satisfied it, the fallback build (which does list punktfunk-cli) was skipped, and the install of a binary nobody had built failed. deb.yml now builds all three, and the guard tests every binary it goes on to install rather than a subset — either change alone fixes it; both together mean the script is correct however it is called. That asymmetry is also why the arm64 leg passed throughout: it pre-builds nothing, so its guard always fired and built all three. arch was already right (`-p punktfunk-cli` in its PKGBUILD, installed at line 255) and the rpm spec ships no CLI, so this was deb-only. Verified: guard truth-tabled (skip when all three present, BUILD when the CLI is missing, BUILD when nothing is), shellcheck clean, and punktfunk-cli builds to target/release/punktfunk on a real Linux box. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:02:36 +02:00
enricobuehlerandClaude Opus 5	907985a0b9	docs(packaging/windows): record the driver-signing fingerprint ... The stable cert is live and CI is signing with it. Fills in the placeholder in both docs and adds the one-liner to check an installed driver against it. Thumbprint 4B8493E7CD565758D335F8F4F05C5A7261A13E02, verified off the .cer a real windows-host build produced on the runner, not from the key material: RSA 3072, valid to 2036, extensions 2.5.29.15/37/14 and nothing else. The decisive part is that the pf-vdisplay and gamepad bundles now carry the SAME thumbprint — the per-build fallback had each script mint its own 2048-bit cert, so they never matched. That is what proves the secret reached the build rather than the fallback quietly running again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 13:01:42 +02:00
enricobuehlerandClaude Opus 5	cec3955872	feat(client/linux): the app icon reaches About — and the launcher, which never had it either ... Adding the icon to the About dialog turned out to be one line and a missing install: the icon existed, but only the flatpak ever shipped it. The deb, rpm, arch and nix entries all carried `Icon=video-display` — a stock monitor glyph — so on every non-flatpak install the launcher, the taskbar and the window switcher have been showing a generic icon this whole time. About would have shown the same nothing. So the icon moves out of `packaging/flatpak/` into `packaging/linux/icons/hicolor/` beside the tray icons, which is where a shared asset belongs, and all five packagings install it to the same hicolor path. The desktop entry names the app's own icon, and `AboutDialog` names the app id — one identity resolved through the icon theme rather than a path anyone has to keep in step. A `PUNKTFUNK_SHOT_SCENE=about` scene comes along so the dialog is capturable like every other surface; that is how the icon above was verified to actually resolve rather than silently falling back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:38:53 +02:00
enricobuehlerandClaude Opus 5	861b1ffe26	fix(packaging/windows): keep the installer-run scripts ASCII, as the gate requires ... windows-host went red at the locale-safety gate: I wrote em-dashes and box-drawing characters into four scripts under packaging/windows/, and that gate exists precisely to stop that. Windows PowerShell 5.1 reads a BOM-less .ps1 in the active ANSI codepage, so a non-ASCII byte mis-decodes on a German box and the script dies with "unterminated string" — which is how the pf-vdisplay driver install once failed silently in the field. The whole reason the install logic moved into the compiled host exe was this exact hazard, and I reintroduced it in the comments. Substituted to ASCII across all four (- for em-dash and the box-drawing rules). No logic touched. The gate's own check now passes locally, all four still parse on the runner, and make-driver-cert.ps1 -TestOnly still runs end to end. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:15:53 +02:00
enricobuehlerandClaude Opus 5	f8cf3a0cf2	fix(packaging/windows): the decoded signing key must not outlive the build ... Both driver builds base64-decode DRIVER_CERT_PFX_B64 to `driver-signing.pfx` on disk and never delete it. The existing cleanup line only removes the EPHEMERAL cert from the store — it is guarded on $cleanupCert, which is null on exactly the path that writes this file. That was harmless while the cert was a per-build throwaway. It is not harmless now: the key is stable and trusted as a machine root on every box that installs punktfunk, so a .pfx sitting in a build directory is a standing credential on the machine that runs build jobs. Every windows-host build would have left one. Adds Remove-SigningPfx, called after the last signing step and from a script-scope trap so a mid-build failure doesn't strand the key either. Verified on the runner: both scripts parse, the key is gone on the success path, gone on the failure path, and a second call is a no-op. The `break` in that trap is explicitness, not correctness. I first wrote it claiming a bare trap would resume past the error and let a build finish with unsigned drivers; measuring on the runner disproved that — bare and break behave identically (exit 1, no resumption) for `throw` at script scope, `throw` inside a function, and a cmdlet error under EAP=Stop. Kept, with the comment saying what was actually measured rather than what I assumed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	30710b689d	feat(packaging/windows): make-driver-cert.ps1 — one command for the signing key ... The runbook was a dozen copy-pasted lines with three separate ways to get it subtly wrong, so it is a script now. It prints the thumbprint, writes the two secret values to files (not to the terminal, so they stay out of scrollback), and never puts the private key in a certificate store — the only thing to clean up is the output folder. `-TestOnly` does a full dry run and keeps nothing. Three things the script exists to get right, all of which bit during testing: Generation uses the .NET CertificateRequest API rather than New-SelfSignedCertificate, so no key container is involved and it works over SSH. New-SelfSignedCertificate fails there with NTE_PERM 0x80090010 — a network logon has no key container. CONSUMING a .pfx still needs one, so the signtool self-test reports SKIPPED over SSH instead of failing; distinguishing "cannot test here" from "test failed" matters, because the first is a property of the session and the second is a broken key. Any other signtool error is still fatal. The extension set is explicit and matches what the drivers have actually been signed with, read off the certs sitting on the runner: KeyUsage=DigitalSignature (critical), EKU=codeSigning (non-critical), SubjectKeyIdentifier, and NO basicConstraints. Improvising here would surface as a failed driver install on a user's machine rather than as a build error, so it copies the known-good shape. .NET's PKCS#12 writer, not OpenSSL — OpenSSL 3's default AES-256/PBKDF2 produces a .pfx that Windows CryptoAPI frequently cannot read. And RandomNumberGenerator for the passphrase, not Get-Random, which is System.Random. Dry-run verified on the windows-amd64 runner: 3072-bit, 10-year, the three expected extensions, self-test correctly SKIPPED with the NTE_PERM reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	622afc2c32	docs(packaging/windows): fix the driver-cert runbook's RNG and secret scope ... Get-Random is System.Random — not a cryptographic RNG, and it had no business generating the passphrase protecting a signing key. Uses RandomNumberGenerator instead (.Create()/.GetBytes() spelling works on both PS 5.1 and PS 7). Scope corrected to repo-level, matching MSIX_CERT_PFX_B64 next door: only unom/punktfunk builds drivers, so there is nothing for an org-level secret to reach. RPM_GPG_PRIVATE_KEY is org-level because other repos publish RPMs. Also records where to run it — interactive logon only (New-SelfSignedCertificate fails NTE_PERM over SSH, no key container on a network logon), and not on the CI runner, which is the one machine that executes build code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	a49858f194	feat(packaging/windows): give the drivers one publisher identity, and give the trust back ... The drivers had no cryptographic identity at all. Every build minted a fresh `CN=punktfunk-driver` cert (build-pf-vdisplay.ps1, build-gamepad-drivers.ps1), and install.rs `trust_cert` adds whatever .cer it finds in the unpacked bundle to machine Root AND TrustedPublisher. So the signature vouched for nothing an attacker couldn't restage — replace the bundle, ship your own cert beside your own driver, install proceeds identically. It was ceremony to make PnP install quietly. Worse, it leaked. `trust_cert` runs once per driver (install.rs:102 and :155), so every upgrade added TWO more self-signed root CAs under the same name, and nothing ever removed them: uninstalling punktfunk left trust behind that the user had no reason to keep granting. So: both build scripts now take a stable cert via DRIVER_CERT_PFX_B64 (they already read the env var — windows-host.yml just never passed it) and fail closed on a v* tag, same rule as the host and MSIX packers. `driver uninstall` purges every `CN=punktfunk-driver` cert from both stores, and `driver install` purges before adding, so an upgrade also collects the historical pile instead of adding to it. Purge-before-add lives ONLY on the pf-vdisplay install path, not the gamepad one. The installer runs vdisplay first and gamepad second; purging in both would have the gamepad leg delete the cert the vdisplay leg just added whenever the two bundles carry different certs — which is exactly what canary's per-build fallback produces. Purging by subject rather than thumbprint is deliberate too: it is what lets one install clean up certs from builds that no longer exist anywhere, and it needs no parsing of certutil's localized output (this module exists because locale-parsed PowerShell broke the driver install on a German box). This does NOT make the driver download authenticated — a self-signed leaf is its own root, so the installer must trust it for the driver to install at all. What it buys is a fingerprint we can publish out-of-band so a substituted driver is detectable, an allowlistable publisher, continuity across releases, and no root accumulation. Attestation signing remains the real fix; documented as such. Documented the key-custody trade honestly in packaging/windows/README.md: a stable key trusted as a machine root on every install is worth stealing in a way a throwaway never was, with no revocation path. CI secret only. ⚠️ The secrets must exist before the next v* tag or the release will fail — that is the guard working, and the generation runbook is in that README. The fingerprint line there is a placeholder until the key is generated. Verified: punktfunk-host compiles clean on the windows-amd64 runner with this install.rs (exit 0, no warnings); both build scripts parse; cargo fmt clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	93902ff60e	feat(packaging/bazzite): the sysext feed is signed, and the client refuses one that isn't ... `punktfunk-sysext` checked the SHA256 of every image it downloaded, which sounds like verification but isn't: SHA256SUMS lives on the same registry as the images it describes, so anything able to replace an image could replace its checksum in the same request. The checksum only ever proved the download wasn't corrupted. Each feed now carries SHA256SUMS.asc, a detached OpenPGP signature over the manifest, and the client verifies it before believing a line of it. The key is packages@unom.io (AF245C506F4E4763) — the same one that already signs our RPMs, so boxes have one key to trust and we have one key to rotate. Its public half is baked into the script rather than fetched from the feed, because a key you fetch from the thing you're authenticating authenticates nothing; gpg (present on Bazzite) does the verifying against a throwaway keyring holding only that key, so "good signature" and "signed by us" are the same statement. Rollout: stable feeds only publish on a tag, so a `--seal` mode re-signs an existing manifest without rebuilding an image, and every rpm.yml run seals the OTHER channel of its Fedora major too. Canary pushes are frequent, so all live feeds seal within a day of this landing and a key rotation propagates without republishing anything. Until a feed is sealed the client refuses it and says so, naming PUNKTFUNK_SYSEXT_ALLOW_UNSIGNED=1 as the informed way through. Two things testing changed. The baked-key fingerprint check compared against an empty string — the armor block is a single-quoted shell literal, so the extracted range carried `FEED_KEY='` on its first line and gpg saw no armor at all; every publish would have "mismatched" and, on a tag, failed the release. And `status` captured fetch_manifest's stderr but only printed it on failure, swallowing the ALLOW_UNSIGNED warning precisely when someone was running unverified. Verified end to end on Bazzite 44 against a file:// feed with a throwaway key: unsigned feed refused; ALLOW_UNSIGNED=1 proceeds and says so; wrong signer rejected; tampered manifest rejected; good signature accepted; `update` exits 1 before touching anything on a bad feed. Publisher side: signs when the baked key matches, refuses on mismatch, refuses with no key, and its signature round-trips through the real client. shellcheck clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	7b053a4a39	fix(packaging/rpm): a release must not publish unsigned RPMs into a gpgcheck=1 repo ... Signing was already live and the docs were half right about it. `RPM_GPG_PRIVATE_KEY` is an ORG-level secret on unom, so it is invisible in this repo's Actions secrets — which reads exactly like "never set up", and both the rpm.yml step name and sign-rpms.sh's header still said "dormant". Checked it on the wire instead: a published punktfunk-web RPM carries an OpenPGP V4 EdDSA header signature from af245c506f4e4763, the same key committed at packaging/rpm/RPM-GPG-KEY-punktfunk. The real gap was the failure mode. README.md hands users a repo file with gpgcheck=1, but sign-rpms.sh exits 0 when the key is missing — so an org secret that got rotated, renamed, or not inherited would publish an unsigned release into a repo that rejects unsigned packages, and every user's `dnf upgrade` would break with us none the wiser. On refs/tags/v* that is now a build failure. Other builds still fall through unsigned so forks and local builds keep working. Docs corrected to match: the org-level location (with a wire-level check that doesn't depend on where the secret lives), the fail-closed rule, and a note that `rpmkeys --checksig` reporting NOKEY still means signed. Guard tested locally: exit 1 on refs/tags/v0.21.0, exit 0 on refs/heads/main and on an unset ref. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	5db93c1156	fix(packaging/windows): a release must not sign itself with a throwaway cert ... Both pack scripts fell back to a fresh `New-SelfSignedCertificate` whenever MSIX_CERT_PFX_B64 was absent, and said nothing about it beyond one Write-Host. That fallback is right for canary and dev builds. On a tag it is not: an ephemeral cert is regenerated per build, so nobody can pin it, and a release signed with one is indistinguishable from a release signed by whoever else got to the artifact. A secret that got renamed, rotated away, or simply wasn't inherited by a new workflow would have downgraded a real release silently and shipped it. pack-msix.ps1 and pack-host-installer.ps1 now resolve -RequireSignedCert (default 'auto' = true iff GITHUB_REF is refs/tags/v*) and throw instead of falling back; pack-host-installer.ps1 also refuses -NoSign on the same condition. Reading GITHUB_REF inside the scripts rather than taking a workflow flag means a future packaging workflow inherits the guard instead of having to remember it. No effect on today's releases: MSIX_CERT_PFX_B64 / MSIX_CERT_PASSWORD are both set as repo secrets, so the supplied-cert branch is the one tag builds take. This only closes the trapdoor underneath it. Verified on the windows-amd64 runner: both files parse, and the guard resolves true for refs/tags/v0.21.0, false for refs/heads/main and for an unset ref, with 'true'/'false' overriding as intended. Not touched: the pf-vdisplay / gamepad driver builds use the same pattern with DRIVER_CERT_PFX_B64, which has no secret behind it — those need attestation signing (a Partner Center action), and a guard there would just fail every tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 5	bf98102714	feat(packaging): ship punktfunk everywhere, and deprecate the session's stray pairing flag ... The rest of C1. A CLI that only exists in a dev tree is not a door anyone can use, so it now builds and installs in deb, rpm, arch, nix, flatpak and MSIX alongside the client and the session. On Windows it gets its own `AppListEntry="none"` application with the alias `punktfunk.exe` — a command, not a Start-menu tile — which is what the Playnite importer will shell to for `punktfunk library <host> --json`. `punktfunk-session --pair` prints a deprecation notice and forwards. Pairing is a trust ceremony and belongs to the brain, fronted by `punktfunk pair` or a shell; a renderer owning one is precisely the mixing of concerns this split exists to undo. It keeps working for a release, because someone's provisioning script is calling it today. Decky's invocations are untouched and verified still working (`--list-hosts` JSON shape unchanged, `--reachable` exit codes unchanged): those flags are a frozen compat contract until Decky migrates to the verbs at its own pace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00
enricobuehlerandClaude Fable 5	5d018eea7c	ci: the supply chain accounts for itself — per-release SBOM, full-tree audits, a real license gate ... CRA Annex I Part II groundwork (see punktfunk-planning design/cra-readiness.md, Phase 1): * sbom.yml + scripts/ci/gen-sbom.sh: every vX.Y.Z release gets a CycloneDX SBOM attached — syft over both Cargo.locks, all Bun/pnpm trees and the Swift Package.resolved (2,667 components), merged with compliance/sbom/manual-components.cdx.json for what no lockfile records (pyrowave/Granite/volk/Vulkan-Headers pins, libvpl, FFmpeg, SDL3, VB-CABLE, punktfunk-gamescope). * audit.yml: bun audit now covers sdk + plugin-kit (not just web), decky's pnpm tree is scanned, and docs-site runs non-blocking until its known CMS-chain advisories are cleared. All shipping trees verified green today. * license-gate: about.toml's allowlist claim is finally enforced — cargo-about 0.9.1 with --fail over BOTH workspaces. The old [crate.clarify] license-only syntax fails to deserialize under 0.9; migrated ring to a per-crate accepted extension and dropped the stale aws-lc-sys entry (workspace is ring-only). Both gates validated green locally. * drivers/Cargo.lock: sync the pf-dualsense→pf-gamepad rename — the crate rename updated the manifest but the Windows-only lockfile was never regenerated; cargo-about's metadata pass caught it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 00:59:29 +02:00