Files
punktfunk/SECURITY.md
T
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

5.4 KiB

Security Policy

punktfunk is a low-latency desktop/game streaming stack. A host is effectively remote control of a machine, so we take security reports seriously and appreciate responsible disclosure.

Reporting a vulnerability

Please report security issues privately by email to security@punktfunk.com.

Do not open a public issue, pull request, or chat/forum post for a suspected vulnerability — that exposes other users before a fix exists.

What to include

The more of this you can give us, the faster we can act:

  • The component and version (e.g. punktfunk-host 0.9.0, Windows or Linux, which client).
  • The impact — what an attacker can do, and from what position (same LAN, a local service account, admin, a paired client, …).
  • Steps to reproduce, a proof-of-concept, or a crash/log if you have one.
  • Any suggested fix or mitigation (optional).

What to expect

We're a small team, so timelines are best-effort, but we commit to:

  • Acknowledge your report within 3 business days.
  • Give an initial assessment (severity + whether we can reproduce) within about 7 days.
  • Keep you updated, and tell you when a fix ships.
  • Credit you in the advisory / release notes when the fix is public — unless you'd rather stay anonymous.

We practice coordinated disclosure: please give us reasonable time to release a fix before publishing details. We aim to resolve valid issues within 90 days and will agree a disclosure date with you.

Scope

In scope — the code in this repository:

  • The host (punktfunk-host), its Windows drivers, and the protocol/crypto core (punktfunk-core).
  • The native clients (Apple, Linux, Windows, Android), the web management console, and the management API.

Known limits — documented behavior, not vulnerabilities (see https://docs.punktfunk.unom.io/docs/security):

  • Admin/SYSTEM already on the host = out of scope. An attacker who is already administrator or SYSTEM on the host owns the machine regardless of punktfunk.
  • The virtual display is a real monitor — any process already in the interactive desktop session can capture it via the normal OS screen-capture APIs, exactly as it could a physical monitor.
  • GameStream/Moonlight compatibility (--gamestream) uses legacy encryption and is documented as opt-in, trusted-LAN-only.
  • Public-internet exposure is unsupported — issues that only arise from exposing the host to the WAN are expected; keep the host on a trusted LAN or a VPN.

If you're unsure whether something is in scope, report it anyway — we'd rather hear about it.

Verifying what you downloaded

Every distribution path is authenticated. Nothing below needs an account or a network round trip to us beyond the download itself.

  • Release-page downloads (DMG, MSIX, setup.exe, APK, decky zip, .deb/.rpm) each ship a <file>.sha256 next to them. In your download directory: sha256sum -c punktfunk-1.2.3.dmg.sha256 (macOS: shasum -a 256 -c …).
  • RPMs from the dnf repo are OpenPGP-signed with packages@unom.io (AF245C506F4E4763); the repo file in packaging/rpm/README.md sets gpgcheck=1, so dnf checks every package for you. rpmkeys --checksig on a downloaded RPM verifies it by hand.
  • The Bazzite sysext feed carries a detached signature over its SHA256SUMS, from that same key. punktfunk-sysext verifies it before installing and refuses a feed it cannot verify — the public key is baked into the script rather than fetched from the feed.
  • Windows installers and MSIX packages are Authenticode-signed; a release build that cannot reach its code-signing certificate fails to build rather than falling back to a self-signed one. Check with Get-AuthenticodeSignature punktfunk-host-setup-1.2.3.exe.
  • The Windows drivers (virtual display, virtual gamepads) are signed with a stable self-signed certificate, CN=punktfunk-driver, whose fingerprint is published in packaging/windows/README.md. The installer has to add it to the machine's trusted roots for a self-signed driver to install at all, so — unlike the cases above — this signature does not authenticate the download: it gives the drivers a stable publisher identity you can compare against the published fingerprint, and it is removed again on uninstall. Verify with Get-AuthenticodeSignature on the installed pf_vdisplay.dll, or list what is trusted with Get-ChildItem Cert:\LocalMachine\Root | ? Subject -like '*punktfunk*'.

A checksum on its own only tells you the download wasn't corrupted in transit — it says nothing about who produced the file, since anyone able to replace an artifact can replace its checksum. Where that distinction matters (the update feeds, the package repos), the checksums are covered by a signature. If a signature check fails, please don't work around it; report it.

Safe harbor

We consider good-faith security research that follows this policy to be authorized, and we won't pursue legal action against researchers who:

  • make a good-faith effort to avoid privacy violations, data loss, and service disruption,
  • only test systems they own or have explicit permission to test,
  • give us reasonable time to remediate before public disclosure,
  • don't exfiltrate more data than needed to demonstrate the issue.

Thank you for helping keep punktfunk and its users safe.