| 1 |
# cargo-audit configuration, triaged advisory posture for the MNW server. |
| 2 |
# |
| 3 |
# Every ignore below is a transitive advisory we cannot resolve by bumping our |
| 4 |
# own direct deps, each with a rationale and (where relevant) the upstream we're |
| 5 |
# waiting on. Directly-fixable advisories are NOT parked here, they get fixed in |
| 6 |
# Cargo.toml/Cargo.lock (e.g. the ammonia mXSS RUSTSEC-2026-0193 was closed by |
| 7 |
# bumping to 4.1.3, not ignored). Re-review this list on every dependency audit. |
| 8 |
|
| 9 |
[advisories] |
| 10 |
ignore = [ |
| 11 |
# rsa, Marvin timing side-channel on RSA *decryption*. Pulled only by the |
| 12 |
# signature-*verification* crates (apple-codesign, authenticode, yara-x); we |
| 13 |
# never decrypt with rsa, so the decryption-oracle attack does not apply. |
| 14 |
"RUSTSEC-2023-0071", |
| 15 |
|
| 16 |
# The rustls-webpki 0.101 trio (RUSTSEC-2026-0098/0099/0104) and the git2 UB |
| 17 |
# pair (RUSTSEC-2026-0183/0184) were dropped on 2026-07-21: the EOL rustls |
| 18 |
# 0.21 stack left s3-storage in d7a50c5a and git2 has since been bumped, so |
| 19 |
# neither advisory is reachable. cargo-deny flags unreachable ignores as |
| 20 |
# `advisory-not-detected`; that is the signal to prune this list. |
| 21 |
|
| 22 |
# Unmaintained-crate warnings, all transitive (no direct dep, no code change |
| 23 |
# available to us). Tracked for when upstreams migrate off them. |
| 24 |
"RUSTSEC-2025-0141", # bincode (unmaintained), via transitive tooling |
| 25 |
"RUSTSEC-2020-0095", # difference (unmaintained), via a dev/test dep |
| 26 |
"RUSTSEC-2025-0134", # rustls-pemfile (unmaintained), via AWS SDK TLS |
| 27 |
"RUSTSEC-2026-0173", # proc-macro-error2 (unmaintained), via a macro dep |
| 28 |
|
| 29 |
# wasmtime 43.0.2, "Stores can mix up type indices between engines" |
| 30 |
# (3.8 low, published 2026-07-31), reached only through yara-x 1.19.0, which |
| 31 |
# is the current release and pins the 43 line. The fixed ranges are 24.0.12+, |
| 32 |
# 36.0.13+, 46.0.2+ and 47.0.3+ — they skip 43 entirely, so there is no |
| 33 |
# version reachable by bumping anything we control. Waiting on yara-x. |
| 34 |
# |
| 35 |
# Not applicable as we run it. The precondition is a store crossing between |
| 36 |
# two wasmtime Engines, and production builds exactly one: scanning/mod.rs:499 |
| 37 |
# calls yara::compile_rules_from_dir once while constructing the ScanEngine, |
| 38 |
# and every other yara_x::Compiler::new() in the tree is under #[cfg(test)]. |
| 39 |
# One engine for the process lifetime means two engines never exist to |
| 40 |
# confuse. THAT is the load-bearing claim here — if a second compile ever |
| 41 |
# lands in a production path, this ignore stops being justified and has to be |
| 42 |
# re-argued (see the note in scanning/yara.rs). |
| 43 |
# |
| 44 |
# Worth being precise about the blast radius rather than calling it isolated: |
| 45 |
# yara-x runs IN-PROCESS, in the server's address space (scanning/mod.rs:192). |
| 46 |
# What does bound it is that scanning happens on a dedicated worker pool off |
| 47 |
# the request path, a panic in a CPU layer is caught and converted to a |
| 48 |
# fail-closed scan_panic verdict rather than unwinding the worker, and the |
| 49 |
# CPU layers carry a wall-clock deadline. Defense in depth, not a sandbox. |
| 50 |
# |
| 51 |
# Monitoring: cargo-deny reports an unreachable ignore as |
| 52 |
# `advisory-not-detected`, so this entry announces its own obsolescence once |
| 53 |
# yara-x moves to a fixed wasmtime. Prune it then. |
| 54 |
"RUSTSEC-2026-0222", |
| 55 |
] |
| 56 |
|