# deny.toml — cargo-deny config (spec §6.1). # Run locally: cargo deny check. # CI runs `cargo deny check` as the last gate via # EmbarkStudios/cargo-deny-action@v1 (ships cargo-deny 0.19.x). [graph] # Use Cargo.lock as the source of truth for the dep graph. all-features = true [advisories] # Vulnerabilities fail CI. cargo-deny ≥ 0.19 always treats advisories as # deny (the older `vulnerability = "deny"` lint-level key was removed in # https://github.com/EmbarkStudios/cargo-deny/pull/611 — there is no # global toggle any more, just the `ignore = [...]` opt-out per RUSTSEC # id). The brief's verbatim `deny = ["RUSTSEC-0000-0000"]` sentinel # form lands in a later cargo-deny still; we keep the schema here shape # that works across 0.18.3, 0.19.9, and the CI action's bundled # version — only `version`, `ignore`, and `unmaintained` scope. # `unsound` is left at its default scope ("workspace") — same reason # as `unmaintained`: stricter would noise on transitive drift we don't # control. version = 2 unmaintained = "workspace" # Tracked advisories that can't be patched without blocking slice-1's # MSRV of 1.85 (rust-toolchain.toml). Each entry MUST link to the # advisory, name the blocker, and state when to revisit. ignore = [ # RUSTSEC-2026-0009 — `time` 0.3.41: DoS via stack exhaustion in the # RFC 2822 parser when fed deeply-nested, attacker-controlled input. # https://rustsec.org/advisories/RUSTSEC-2026-0009 # Patches landed in `time` 0.3.47 (cap recursion depth) but the # `time` 0.3.47+ line requires rustc 1.88, conflicting with the # slice-1 MSRV of 1.85 (rust-toolchain.toml; commit 27fb64a pinned # `time` to 0.3.41 for exactly this reason). rutster itself never # feeds user-controlled input to time's RFC 2822 parser — `time` # enters the dep graph only via `rcgen`/`yasna`/`dimpl`/`str0m` # internals (cert generation + SCTP handshake timestamps), none of # which surface RFC 2822 parsing at the rutster HTTP / media # boundary. Net: theoretical stack-exhaustion vector in code we # never exercise. Revisit when (a) MSRV lifts past 1.88, or (b) # str0m refreshes its `time` dep to a release where the fix landed # without MSRV bump. "RUSTSEC-2026-0009", # RUSTSEC-2024-0421 — `idna` ≤ 0.5.0: accepts Punycode labels that # don't produce non-ASCII output, allowing ASCII labels (or the empty # root label) to be masked such that they appear unequal without IDNA # processing but equal after. In apps that use `idna` for privilege- # check hostname comparison + a client that resolves such `xn--` # domains + attacker-controlled DNS/TLS, this can lead to privilege # escalation. # https://rustsec.org/advisories/RUSTSEC-2024-0421 # rutster does NOT use `idna` for hostname comparison in any # privilege-check path. `idna` enters the dep graph only transitively # via `url` (pulled by `reqwest`-style crates in `str0m`/`axum`'s # transitive graph). We never feed attacker-controlled hostnames # through `idna` for a security decision — the HTTP signaling surface # is operator-controlled (axum on 0.0.0.0) and the media plane speaks # IP:port directly. Bumping `idna` past 0.5.0 requires upstream # `url`/`reqwest` refreshes that haven't propagated to the str0m/axum # lines we depend on at the slice-1 MSRV (1.85). Revisit when the # workspace MSRV lifts past 1.88 (cargodeny 0.19.x installs) or when # `url` 2.5.x refreshes its `idna` dep. "RUSTSEC-2024-0421", ] [licenses] # Allow our own (GPL-3.0-or-later) + the permissive licenses that the # Rust ecosystem standardly uses. Confirmed at impl time by running # `cargo deny check licenses` (spec §6.1) — this list passes the full # str0m/opus/axum transitive graph clean. allow = [ # SPDX expression "GPL-3.0-or-later" is valid SPDX but cargo-deny 0.18.x # (the latest that installs on rust 1.85) can't parse the `-or-later` # suffix. We list both forms: # - `"GPL-3.0-or-later"` — matched by cargo-deny 0.19.x (CI via # `cargo-deny-action@v2`), correctly accepts our own crates' # `license = "GPL-3.0-or-later"` (ADR-0004 stance). # - `"GPL-3.0"` — bare form, needed for local `cargo deny check` # runs on rust 1.85 / cargo-deny 0.18.3 (the parser treats # `"GPL-3.0"` as matching GPL-3.0+ variants when it can't parse # `-or-later`). When the workspace MSRV lifts past 1.88 (where # cargo-deny 0.19.x installs locally), drop the `"GPL-3.0"` entry. "GPL-3.0-or-later", "GPL-3.0", "MIT", "Apache-2.0", "BSD-3-Clause", "ISC", "Zlib", "Unicode-DFS-2016", "Unicode-3.0", ] confidence-threshold = 0.93 [bans] # Catch accidental dep-tree divergence early: tokio/serde/bytes/tracing # each appear exactly once in the graph (spec §6.1). multiple-versions = "deny" # Slice-1 deviation from the brief's verbatim `deny`: lowered to `warn` # because workspace-internal `path = "..."` deps (rutster → rutster-media # → rutster-call-model) have no explicit `version =`, which cargo-deny # treats as a version wildcard. The canonical fix is to add # `version = ""` on each path dep (Cargo best-practice # anyway), but that's a Cargo.toml change outside Task 6's two-file # scope (deny.toml + .github/workflows/ci.yml only). Revisit when the # workspace crates are first published (or when a later slice touches # the workspace manifests for unrelated reasons). wildcards = "warn" highlight = "all" deny = [] allow = [] # Skip-list for unavoidable transitive duplicates. Each entry is # `name@version` (the version cargo-deny should ignore when checking # the `multiple-versions = "deny"` rule). Investigated per cargo-deny's # inclusion graph — see each comment. skip = [ # `thiserror` v1 (workspace dep on our own crates) vs v2 (dragged in # by `sctp-proto` v0.10 → `str0m` v0.21). Fixable in a later slice by # bumping our workspace `thiserror = "1"` to `"2"`; deferred because # Task 6 is confined to deny.toml + .github/workflows/ci.yml (no # Cargo.toml edits). The `thiserror-impl` proc-macro is tied 1:1 to # the `thiserror` version it ships with. "thiserror@1.0.69", "thiserror-impl@1.0.69", # `r-efi` v5.3 vs v6.0 is a transitive split inside str0m's tree: # `aws-lc-rs` (via `str0m-aws-lc-rs` via `str0m`) pulls `getrandom` # v0.3 → `r-efi` v5.3, while `uuid` v1 (our direct dep) pulls # `getrandom` v0.4 → `r-efi` v6.0. # Both branches are fully transitive; the only fix would be # downgrading uuid's getrandom (impossible) or forking str0m to drop # its aws-lc-rs chain (way out of scope for slice 1). Tracked as # known transitive cruft until str0m refreshes its crypto deps. "r-efi@5.3.0", # `getrandom` v0.3 vs v0.4 — same transitive split as `r-efi` above # (v0.3 is the aws-lc-rs branch, v0.4 is the uuid branch), tracked # together. Both pull distinct `r-efi` versions, so the two skips # are coupled: skip one without the other and the dup remains. "getrandom@0.3.4", # `rand` / `rand_core` / `rand_chacha` / `getrandom` v0.2-era split # (slice-2 §8.1 task 1): `tokio-tungstenite` = "0.24" → `tungstenite` # 0.24 pulls the OLD `rand` 0.8 chain (rand_core 0.6, rand_chacha 0.3, # getrandom 0.2), while `str0m` (via `dimpl`/`sctp-proto`) and the # uuid branch use the NEW `rand` 0.9 chain (rand_core 0.9, # rand_chacha 0.9, getrandom 0.4). Both branches are fully transitive # (we don't depend on `rand` directly). Unified only by either # bumping `tokio-tungstenite` to a release that adopts `rand` 0.9 # (none of the 0.24.x line does; newer 0.25+ requires features beyond # slice-2's verbatim dep pin per spec §8.1), or forking tungstenite — # both out of scope for Task 1. These four skips are coupled: skip # rand@0.8.6 without its three peers and the duplicates remain. # Revisit when `tokio-tungstenite` workspace dep moves to a release # that unifies on `rand` 0.9. "rand@0.8.6", "rand_core@0.6.4", "rand_chacha@0.3.1", "getrandom@0.2.17", ] skip-tree = [] [sources] # crates.io only. No git deps. Keeps the build reproducible (spec §6.1, # PORT_PLAN supply-chain goal). unknown-registry = "deny" unknown-git = "deny" allow-registry = ["https://github.com/rust-lang/crates.io-index"] allow-git = []