5 Commits

Include renames

Author	SHA1	Message	Date
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	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 4.8	e93bc3f7b8	fix(windows-installer): pf-vdisplay CI build - default target dir + non-fatal cat guard ... The CI driver build panicked in wdk-sys's build script - "a Cargo.lock file should exist in the same directory as the top-level Cargo.toml". wdk-build's find_top_level_cargo_manifest() walks UP from OUT_DIR for the first ancestor holding a Cargo.lock and explicitly does NOT support non-default target dirs - but build-pf-vdisplay.ps1 pointed CARGO_TARGET_DIR at an out-of-tree dir (to isolate from CI's shared C:\t), so no ancestor of OUT_DIR had a Cargo.lock. Build into the driver workspace's DEFAULT target dir instead (its ancestors include the driver Cargo.lock); the driver's own [workspace] already isolates it and it has no CMake deps needing C:\t. Also make the Test-FileCatalog coverage guard non-fatal (it can't open a catalog signed by a not-yet-trusted cert). Validated on the runner with CARGO_TARGET_DIR=C:\t. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 14:58:20 +00:00
enricobuehlerandClaude Opus 4.8	546b8e2e29	fix(windows-installer): build pf-vdisplay from source in CI; ASCII scripts; upgrade-safe web console ... The pf-vdisplay virtual-display driver shipped as a checked-in PREBUILT binary that went stale - two field failures on a fresh install (live-repro'd on a German-locale Dell laptop): * Bug A (every box): a repo-wide rename edited the vendored pf_vdisplay.inf but never re-signed pf_vdisplay.cat, so the catalog stopped covering the INF -> `pnputil /add-driver` fails SPAPI_E_FILE_HASH_NOT_IN_CATALOG -> driver never installs -> every session dies "pf-vdisplay driver interface not found". * the prebuilt binary also predated IOCTL_SET_RENDER_ADAPTER (added to the driver source after the vendor freeze) that the host needs to pin the IDD render GPU on hybrid/Optimus boxes. Fix: build the driver FROM SOURCE every release (build-pf-vdisplay.ps1, wired into pack-host-installer.ps1) so .dll/.inf/.cat are always in lockstep and current driver features ship. The runner's clang 22 made the driver's pinned bindgen 0.71 emit opaque structs (157 layout-assert errors), so bump the vendored wdk-sys/wdk-build bindgen 0.71 -> 0.72 (+ lock). The build self-signs the driver per build (installer trusts the bundled .cer); a stable DRIVER_CERT_PFX_B64 secret can override. * Bug B (non-English boxes): the installer runs install-pf-vdisplay.ps1 etc. via powershell.exe (5.1), which reads a BOM-less script in the ANSI codepage - an em-dash's trailing 0x94 byte becomes a curly quote on German Windows-1252 and the script aborts "unterminated string", so the driver never installed (the gamepad script survived only because it was already ASCII). Scrub every installer-run .ps1/.cmd to ASCII + add a CI gate that fails on any non-ASCII so it can't regress. * Bug C (upgrades): nothing stopped the OLD web console before re-registering its task, so a stale server kept :3000 (the new one restart-looped on EADDRINUSE) and served a broken old bundle (500 on /login). Stop + reap it (runtime-agnostic, by the :3000 listener owner) in web-setup.ps1 and in the .iss before the file copy + on uninstall. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 14:33:34 +00:00