30 Releases 34 Tags

RSS Feed

• v0.16.0 191c9a4e18

  Compare

  v0.16.0 Stable

  enricobuehler released this 2026-07-20 05:47:58 +00:00 | 48 commits to main since this release

  Wire-compatible with 0.15.x and 0.14.x (WIRE_VERSION stays 2) and the virtual-display driver protocol is unchanged at v4 — existing pairings, clients and installed drivers keep working, with no re-pairing and no driver update required.

  This release is about who is allowed to do what — the plugin runner stops being a full-privilege process, and the video data plane stops trusting an unauthenticated packet — plus the long tail of defects a systematic sweep of the core, capture, encode, zero-copy and inject crates turned up.

  The data plane now requires the authenticated peer

  The UDP hole-punch adopted the source address of any datagram whose first 8 bytes matched PUNCH_MAGIC — a fixed public constant with no key, nonce or session id — and the authenticated QUIC peer was consulted only as the no-punch fallback, so it never validated anything. Hole-punch is the default bring-up path and the data socket is an OS ephemeral port, so spraying the ephemeral range during the 2500 ms punch window let an attacker on the network take over the video plane: the legitimate client is then filtered out and receives nothing, while QUIC stays healthy so no reconnect fires. With a spoofed source address, the same 8 bytes could aim a full-rate video stream at an uninvolved third party.

  The punch is now required to match the authenticated peer's IP. Also in the same pass: adaptive FEC no longer wedges on large frames.

  The plugin runner is no longer privileged

  Operator-installed plugin code used to run with far more authority than it needs. Four changes take that away:

  • It no longer holds the console's admin token. The scripting runner previously carried the full-admin management token, so a plugin defect could rewrite hooks.json — arbitrary command execution — or administer pairing. The host now mints a second, separately persisted secret (plugin-token) with its own auth lane: loopback-confined like the admin token, but explicitly denied /hooks (read and write), everything under /pair, /native/pair, /native/pending, client unpair deletes, and other plugins' UI credentials. Everything a plugin legitimately does — status, library, events, sessions, its own UI lease — is untouched.
  • On Windows it runs as LocalService, not SYSTEM. The scheduled task ran plugin code as SYSTEM with RunLevel Highest; any plugin defect was a full compromise of the machine. The principal is now NT AUTHORITY\LocalService, and plugins enable converges an older SYSTEM-registered task idempotently before starting it, so existing installs migrate. It grants read on exactly the two files the runner needs — the scoped plugin token and the TLS pin — and never the admin token. plugins status prints the principal so you can verify the migration.
  • Public-registry installs are gated. resolvePackage() used to hand any plugin-shaped name straight to bun add, so a typo or a squatted look-alike on npmjs.org would install operator-privileged code. Only the @punktfunk scope (pinned to the Gitea registry) resolves by default; anything else needs --allow-public-registry and prints a loud warning. Removal is never gated — uninstalling stays safe regardless of origin.
  • The systemd user unit is sandboxed — NoNewPrivileges, PrivateTmp, ProtectSystem=strict with ReadWritePaths=%h, and address families restricted to Unix and IP.

  Windows unit-file trust is enforced properly too: fileIsSafe() returned true unconditionally on win32 with an "ACL check is a follow-up" note. It now reads the unit's SDDL and refuses unless the owner is SYSTEM, Administrators, TrustedInstaller or the runner's own account, with no other principal holding a write-capable ACE — matching what the Unix mode-bits path always did.

  Two things follow from de-privileging, both added here: a dedicated writable plugin-state directory (a LocalService runner can't write under %ProgramData%\punktfunk, so a state-writing plugin's first-run mkdir and saveCache failed EPERM), and an ingest inbox — <config_dir>\ingest, writable by BUILTIN\Users — because the de-privileged runner can no longer traverse your user profile to read what an app running as you produced. The acute case is the Playnite exporter's library JSON under %APPDATA%. An interactive app drops files in ingest\<plugin>\… and the runner reads them there.

  If you run plugins, note

  • A script that genuinely needs the admin surface must now set PUNKTFUNK_MGMT_TOKEN explicitly. The SDK's zero-config connect() prefers the scoped plugin token automatically, and hosts without one fall back to the old behaviour unchanged.
  • Installing anything outside the @punktfunk scope now requires --allow-public-registry.
  • Plugins writing outside $HOME on Linux, or on distros restricting unprivileged user namespaces for user units, may need a documented systemctl --user edit drop-in.

  Latency measured where it actually happens

  Two wired Mac clients sat at a rock-steady ~18–19 ms of reported network latency that outlived the load causing it and cleared only on reconnect. It was not the network. Receipt was stamped when the embedder pulled a frame rather than when reassembly completed, so client-side queueing was silently attributed to the link and was invisible from the HUD. The core now stamps receipt as the access unit crosses the session boundary; the Apple client keeps the pull instant separately and reports the gap as its own client queue term (detailed HUD tier from 2 ms, plus queue_p50 in the stats log). Decode stages keep their pull anchor everywhere, so no existing stage changes meaning.

  Separately, a small constant elevation was never recovered from: the jump-to-live detectors ignore anything under 6 queued frames or 400 ms behind, so a sub-frame standing backlog — or a stale clock offset after a wall-clock step — was carried for the whole session. A third detector now watches for a window-minimum one-way delay ≥ 10 ms above the session floor with zero loss for ~4.5 s and escalates gently: a free clock re-sync first, then at most three flush-and-keyframe bleeds sharing the jump-to-live cooldown, then a loud disarm. Loss windows reset the run — congestion belongs to FEC and ABR.

  Loss recovery, finished

  0.15.0 made LTR-RFI recovery sound under sustained loss; two paths were still short. Vulkan Video never received that taint sweep — recovery-slot selection accepted any resident slot older than the current loss, but "resident and older" is not "the client decoded it", so a later loss could anchor on an undecodable frame and ship it tagged as a recovery anchor. QSV's sweep was incomplete in its most common case: with two LTR slots, "exactly one swept" is the ordinary situation, and the rejection loop skipped precisely the entry the sweep exists to distrust. Both now match AMF. Driver-reported encode feedback is also bounds-checked against the bitstream buffer instead of trusted.

  The capture / encode / zero-copy / inject sweep

  A systematic review of those crates landed, and the results are mostly invisible until they bite:

  • A wedged GPU could park the one thread that recovers the session. Vulkan Video's backpressure fence waited with u64::MAX on the host encode thread — the same thread the stall watchdog's reset() runs on — so there was no error, no reset, and teardown blocked on the join. This is the default encode path on AMD and Intel Linux hosts. Now bounded, with expiry surfaced as an error.
  • A failed Vulkan Video open leaked everything it had built — around 20 objects across 15 fallible steps, including a VkDevice and GPU memory per retried open, on a path where transient failure is expected. Teardown is now a guard that unwinds any prefix of the build.
  • Remote input could be frozen by a peer. The Steam Deck gadget's drop joined a thread parked in a blocking no-timeout ioctl, so the join hung — on the session input thread, driven by the client's active pad mask, meaning a remote peer clearing its pad bit could freeze all session input.
  • Capture could silently wedge while still reporting healthy. A caught panic in the PipeWire .process callback unwound past every requeue and permanently stranded that buffer; once the pool drained, capture stopped while still reporting negotiated and active.
  • Torn frames on Windows NVENC. Async pipelining depth was bounded by an encoder-side cap that consulted nothing about the capturer, despite a comment claiming otherwise — so the encoder could still be reading a texture the capturer had already handed out and overwritten. It is now bounded by the capturer's ring.
  • A PyroWave plane-import cache keyed on raw texture pointers could return an image bound to a texture that no longer existed once the capturer recycled its ring at identical dimensions. Now keyed on the capturer's ring generation.
  • Plus: error-path leaks that recurred every frame for a worker's lifetime, an odd-height NV12 overrun, a cursor-metadata out-of-bounds read, a GL→CUDA copy race, an exception-unsafe fence wait, and a heap-allocated PnP callback context (a late completion could previously corrupt a reused stack frame and signal a recycled handle).

  Connection tests and control frames

  • "Test connection" could corrupt automatic bitrate. There is one probe slot per session and no correlation id, but two independent requesters share it: the pump's startup link-capacity probe and the embedder's request_probe behind the shipped "Test connection" button in the Windows and Linux apps. They collide by default — both apps probe right after connect, and the pump's own probe fires two seconds later, inside that burst — and only the startup path had a busy check, a watchdog and a window rebase. Four defects in that one cluster are fixed.
  • Control-stream reads are cancel-safe now. Message framing used two read_exact calls, which quinn documents as explicitly not cancel-safe — bytes already taken live only in the future's buffer and are lost on drop. Both long-lived control loops drive that read from a select! with no biased;, so any sibling becoming ready could drop a partially-read frame. A frame only has to straddle two wakeups to bite, and a clipboard offer can reach ~2 KB, exceeding one QUIC packet.

  Also in this release

  • Management commands are quiet again. punktfunk-host plugins add … printed the host startup banner and, on Windows, ran a GPU-preference hook whose DPI probe emitted an alarming access denied warning that read like a failure. Management verbs now skip both; the SCM-launched service run is deliberately unaffected.
  • The plugin/script runner is always deployed on Windows.

  Note for embedders

  The C ABI moves from 8 to 9 — PunktfunkFrame grows a received_ns field. The wire protocol is untouched, so this affects only code linking the punktfunk core directly; every client shipped from this tag is built against it.

  Downloads

  • Punktfunk-0.16.0.dmg
    7.5 MiB

    2026-07-20 06:16:00 +00:00
  • punktfunk-0.16.0-1-x86-64.f43.raw
    52 MiB

    2026-07-20 06:53:34 +00:00
  • punktfunk-0.16.0-1-x86-64.f44.raw
    52 MiB

    2026-07-20 06:53:28 +00:00
  • punktfunk-0.16.0-1.fc43.x86_64.bazzite.rpm
    9.1 MiB

    2026-07-20 06:52:48 +00:00
  • punktfunk-0.16.0-1.fc44.x86_64.fedora-44.rpm
    9.2 MiB

    2026-07-20 06:52:41 +00:00
  • punktfunk-0.16.0.aab
    12 MiB

    2026-07-20 06:31:32 +00:00
  • punktfunk-0.16.0.apk
    19 MiB

    2026-07-20 06:31:41 +00:00
  • punktfunk-0.16.0.zip
    48 KiB

    2026-07-20 06:21:39 +00:00
  • punktfunk-client-0.16.0-1-x86_64.pkg.tar.zst
    14 MiB

    2026-07-20 06:32:53 +00:00
  • punktfunk-client-0.16.0-1.fc43.x86_64.bazzite.rpm
    12 MiB

    2026-07-20 06:52:54 +00:00
  • punktfunk-client-0.16.0-1.fc44.x86_64.fedora-44.rpm
    12 MiB

    2026-07-20 06:52:44 +00:00
  • punktfunk-client-0.16.0.flatpak
    12 MiB

    2026-07-20 07:01:47 +00:00
  • punktfunk-client-windows_0.16.0.0_arm64.cer
    768 B

    2026-07-20 07:34:54 +00:00
  • punktfunk-client-windows_0.16.0.0_arm64.msix
    43 MiB

    2026-07-20 07:34:53 +00:00
  • punktfunk-client-windows_0.16.0.0_x64.cer
    768 B

    2026-07-20 07:39:00 +00:00
  • punktfunk-client-windows_0.16.0.0_x64.msix
    69 MiB

    2026-07-20 07:38:59 +00:00
  • punktfunk-client_0.16.0_amd64.deb
    12 MiB

    2026-07-20 06:28:55 +00:00
  • punktfunk-host-0.16.0-1-x86_64.pkg.tar.zst
    11 MiB

    2026-07-20 06:32:56 +00:00
  • punktfunk-host-setup-0.16.0.exe
    74 MiB

    2026-07-20 07:51:26 +00:00
  • punktfunk-host-windows_0.16.0.cer
    768 B

    2026-07-20 07:51:27 +00:00
  • punktfunk-host_0.16.0_amd64.deb
    20 MiB

    2026-07-20 06:29:55 +00:00
  • punktfunk-scripting-0.16.0-1-x86_64.pkg.tar.zst
    33 MiB

    2026-07-20 06:33:05 +00:00
  • punktfunk-scripting-0.16.0-1.fc43.x86_64.bazzite.rpm
    26 MiB

    2026-07-20 06:53:06 +00:00
  • punktfunk-scripting-0.16.0-1.fc44.x86_64.fedora-44.rpm
    26 MiB

    2026-07-20 06:52:53 +00:00
  • punktfunk-scripting_0.16.0_amd64.deb
    26 MiB

    2026-07-20 06:29:02 +00:00
  • punktfunk-web-0.16.0-1-x86_64.pkg.tar.zst
    36 MiB

    2026-07-20 06:33:14 +00:00
  • punktfunk-web-0.16.0-1.fc43.x86_64.bazzite.rpm
    30 MiB

    2026-07-20 06:53:20 +00:00
  • punktfunk-web-0.16.0-1.fc44.x86_64.fedora-44.rpm
    30 MiB

    2026-07-20 06:53:05 +00:00
  • punktfunk-web_0.16.0_amd64.deb
    30 MiB

    2026-07-20 06:29:10 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)