forked from unom/punktfunk
enricobuehler
51a005dd43
Acting on the 2026-08-13 dependency sweep. Every claim below was re-verified against
the tree before acting on it (greps carry a positive control; the advisories were
re-checked with cargo audit 0.22.2).
SECURITY
- event-listener 5.4.1 -> 5.4.2 (RUSTSEC-2026-0221, unsound Send/Sync on StackSlot;
reaches the tray via zbus and the host via ashpd). This sat unnoticed because
`cargo audit` reports unsoundness as a WARNING and the job fails only on
vulnerabilities — audit.toml now says so out loud.
- spin 0.9.8 -> 0.9.9. 0.9.8 is YANKED and was genuinely compiled (flume via mdns-sd
and relm4, plus lazy_static).
- wayland-scanner 0.31.10 -> 0.31.11, which moves quick-xml 0.39 -> 0.41. That is the
exact trigger audit.toml documented for RUSTSEC-2026-0194/0195, so both ignores are
deleted rather than left as permanent exceptions. Only RUSTSEC-2023-0071 (rsa
Marvin, still unfixed upstream) remains.
- Corrected audit.toml's claim that `paste` arrives "via utoipa-axum": rav1d pulls it
too, so every client has it through the decode path and dropping utoipa-axum would
not have cleared it.
TWO CI GATES THAT SCANNED NOTHING
- `cargo audit` only ever reads the ROOT Cargo.lock. The drivers lock was already in
this job's `paths:` filter, so edits to it triggered a run that then ignored them.
All four secondary workspaces now get an explicit `--file` (verified: clean, bar the
known `paste` warning in drivers).
- packaging/windows/pf-vkhdr-layer had NO lockfile at all while shipping as a DLL in
the host installer, so every build resolved fresh and neither cargo-audit nor
cargo-about ever saw it. Lockfile generated and committed, and added to `paths:`.
UNUSED / DUPLICATE DECLARATIONS
- punktfunk-host: removed 13 dependencies it never references — the Wayland stack
(client, protocols{,-wlr,-misc}, scanner, backend), xkbcommon, reis, khronos-egl,
ash, usbip-sim, parking_lot, bytemuck. The code moved to pf-inject and pf-zerocopy
in the subsystem extraction and those crates declare them; only the manifest entries
and their now-false comments stayed. Also dropped four redundant re-declarations
(tokio/serde_json/futures-util in the Linux block, tower in dev-deps).
- Removed genuinely unused: bytes (punktfunk-core), anyhow (pf-win-display),
tracing (clients/cli), anyhow (clients/session), serde (clients/windows).
- Removed the high-level `wdk` crate from all five driver crates and the drivers
workspace: none of them ever referenced `wdk::` (62 `wdk_sys::` uses; pf-umdf-util
is a full WDF crate that never declared it). `tracing`/`tracing-subscriber` remain
in that lock afterwards but ONLY as wdk-sys build-dependencies, not in the DLLs.
- pf-win-display took punktfunk-core with `quic` for one type (`Mode`) that lives in
the ungated `config` module; now `default-features = false`, which keeps
quinn/tokio/rcgen/opus out of a leaf crate's declared closure.
- pf-encode declared the windows-rs feature `Wdk_Graphics_Direct3D` for a call that
lives in pf-frame and is resolved via GetProcAddress on gdi32.
LATENT BREAKAGE (compiled only by feature unification)
- pf-inject uses `tokio::select!` without declaring `macros` (borrowed from
punktfunk-core's quic feature); pf-capture uses `tokio::sync::oneshot` without
declaring `sync` (borrowed from ashpd->zbus); pf-client-core uses the `minwindef`
and `winnt` windows-rs headers without declaring them (borrowed from
clients/windows). Each now declares what it uses, so an unrelated crate changing its
features cannot break them.
- pf-console-ui took pf-client-core WITHOUT `default-features = false`, unlike every
other consumer. That default is `pyrowave`, which compiles the vendored PyroWave C++
— "fatal on Windows ARM64". Only safe today because the ARM64 leg passes
--no-default-features (which also drops `ui`).
CORRECTED A FALSE INVARIANT
- clients/windows claimed "the workspace builds ONE windows-rs". It does not: wasapi
pulls the crates.io windows 0.62.2 beside the git-rev copy. The invariant that DOES
hold is narrower (reactor and that crate share one rev, which is what makes the
IDXGISwapChain1 hand-off type-check). Comment rewritten, with a warning against
"fixing" it via a blanket [patch.crates-io] — this rev uses header-named features
while a dozen other manifests use the old Win32_* namespace ones.
Plus the safe in-compat `cargo update` sweep (no manifest edits).
Verified on macOS: punktfunk-core 385, pf-update-check 32, c_abi 1 (with
LIBRARY_PATH=/opt/homebrew/opt/opus/lib), cargo audit clean bar the two known
unmaintained warnings. Linux and Windows legs follow.
51 lines
3.8 KiB
TOML
51 lines
3.8 KiB
TOML
# cargo-audit configuration — consumed by `.gitea/workflows/audit.yml` (`cargo audit`).
|
|
#
|
|
# Silence only advisories that are KNOWN-UNFIXABLE and either not applicable to how we use the crate
|
|
# or an accepted, documented risk. Keep this list TIGHT and justify every entry — an ignore here
|
|
# means the audit job stops flagging it, so the reasoning must hold up.
|
|
#
|
|
# ⚠ NOTE: `cargo audit` (no `--deny warnings`) fails only on *vulnerabilities* — `unmaintained` AND
|
|
# `unsound` advisories are warnings that do NOT fail CI. That is deliberate for the two unmaintained
|
|
# crates below, but it does mean an unsoundness can sit here unnoticed: RUSTSEC-2026-0221
|
|
# (event-listener) did exactly that until the 2026-08-13 sweep. Read the job's warnings, not just
|
|
# its exit code.
|
|
#
|
|
# The two unmaintained ones, both transitive with no successor to bump to, left visible on purpose
|
|
# so we keep getting the maintenance signal:
|
|
# * audiopus_sys via opus (opus itself IS maintained; only its -sys layer is stuck).
|
|
# * paste via BOTH utoipa-axum (host) and rav1d (client decode path) — an earlier version of this
|
|
# note named only utoipa-axum, which would have made dropping utoipa-axum look like it cleared
|
|
# paste. It would not: every client pulls it through rav1d.
|
|
# (rustls-pemfile was dropped 2026-06-29 by removing axum-server's unused tls-rustls feature +
|
|
# moving our own PEM parsing to rustls-pki-types; memmap2's unsoundness was fixed by the 0.9.11
|
|
# bump.)
|
|
|
|
[advisories]
|
|
ignore = [
|
|
# rsa "Marvin Attack" (RUSTSEC-2023-0071): a timing side-channel in the rsa crate's variable-time
|
|
# modular exponentiation of the SECRET exponent. IMPORTANT — this affects the RSA private-key op in
|
|
# general, INCLUDING signing (m^d mod n), which the host DOES perform (gamestream/pairing.rs
|
|
# `signing_key.sign(&serversecret)`). It is NOT, as an earlier version of this note wrongly claimed,
|
|
# limited to decryption — so "the vulnerable path isn't exercised" is false; signing exercises it.
|
|
# We accept it because the attack is not practically reachable here, NOT because the path is unused:
|
|
# * No RSA decryption / PKCS#1v1.5 padding oracle exists anywhere (every `decrypt` in the tree is
|
|
# AES/AES-GCM), so the classic Bleichenbacher/Marvin chosen-ciphertext oracle is absent.
|
|
# * The only signed message (`serversecret`) is HOST-generated random, never attacker-chosen — so
|
|
# there's no adaptive chosen-input probing (the lever remote RSA-timing key recovery needs); and
|
|
# signing is gated behind the operator-entered pairing PIN, ONE signature per ceremony (a
|
|
# repeated phase-3 is rejected — gamestream/pairing.rs — to deny a passive timing-sample harvester).
|
|
# * GameStream is OFF by default (bare `serve` is native-only); the secure native QUIC plane uses
|
|
# rustls' constant-time backend, NOT the rsa crate. RSA is touched only on the opt-in,
|
|
# trusted-LAN GameStream/Moonlight pairing handshake. Moonlight mandates RSA-2048, so the
|
|
# GameStream identity cannot move to Ed25519/ECDSA (only the native identity could, and it
|
|
# already avoids the rsa crate).
|
|
# There is NO fixed rsa release (the constant-time rewrite is still unreleased upstream). Revisit if:
|
|
# a constant-time rsa ships (then drop this), the host ever signs an attacker-chosen message with
|
|
# this key, or any RSA decryption / key-transport using the private key is added.
|
|
"RUSTSEC-2023-0071",
|
|
# The quick-xml DoS pair (RUSTSEC-2026-0194/0195) used to be ignored here, with the note
|
|
# "revisit when wayland-scanner releases against quick-xml >=0.41". It has: wayland-scanner
|
|
# 0.31.11 moved to `quick-xml ^0.41` and the lock is on 0.41.0 as of 2026-08-13, so both
|
|
# entries were dropped rather than left as permanent exceptions.
|
|
]
|