[vibesoftwarecoder]

Second step of USB forwarding, after ApolloVibe #12 (which answers the capability check as "disabled"). This adds building blocks only: no settings, no stream hooks, and nothing a user can see yet.

What it adds

• GET /api/v1/usb-forwarding on the paired HTTPS port, with a 5 s timeout, a 4096-byte cap, no redirects, and an exact-certificate pin.
• A TLS tunnel that pins the paired certificate, presents the client certificate, and never logs the token.
• A Windows backend for usbipd-win. It resolves usbipd by absolute path (service path or Program Files, never PATH or the working directory), refuses links and user-writable locations, and builds elevated commands only from a validated bus id or GUID.
• Linux and macOS compile to a stub that reports "unsupported".
• NvHTTP::openConnection gets an optional max-response-size argument. With the default, every existing caller behaves exactly as before.

Tests

• 6 standalone Qt Test projects under tests/ (153 tests passing, 1 skipped), loopback only, with a runner script. They use fake TLS servers, an impostor certificate, a planted fake usbipd, and real link and access-rights cases.
• Each security check was broken on purpose to confirm a test fails, then restored.
• An independent security review found nothing Critical or High. Its Medium and Low findings are fixed, except two follow-ups for the UI phase: a non-blocking elevation wait, and a keepalive after the handshake.

Not covered

• The full app build (CI builds it), a live host, and any real USB device.
• The positive "installed usbipd is trusted" case and the elevated-token case, because usbipd-win is not installed on the test machine.

Derived from qiin2333/moonlight-qt (GPL-3.0); each ported file says so at the top.

🤖 Generated with Claude Code