# cargo-audit configuration, triaged advisory posture for the MNW server.
#
# Every ignore below is a transitive advisory we cannot resolve by bumping our
# own direct deps, each with a rationale and (where relevant) the upstream we're
# waiting on. Directly-fixable advisories are NOT parked here, they get fixed in
# Cargo.toml/Cargo.lock (e.g. the ammonia mXSS RUSTSEC-2026-0193 was closed by
# bumping to 4.1.3, not ignored). Re-review this list on every dependency audit.

[advisories]
ignore = [
    # rsa, Marvin timing side-channel on RSA *decryption*. Pulled only by the
    # signature-*verification* crates (apple-codesign, authenticode, yara-x); we
    # never decrypt with rsa, so the decryption-oracle attack does not apply.
    "RUSTSEC-2023-0071",

    # The rustls-webpki 0.101 trio (RUSTSEC-2026-0098/0099/0104) and the git2 UB
    # pair (RUSTSEC-2026-0183/0184) were dropped on 2026-07-21: the EOL rustls
    # 0.21 stack left s3-storage in d7a50c5a and git2 has since been bumped, so
    # neither advisory is reachable. cargo-deny flags unreachable ignores as
    # `advisory-not-detected`; that is the signal to prune this list.

    # Unmaintained-crate warnings, all transitive (no direct dep, no code change
    # available to us). Tracked for when upstreams migrate off them.
    "RUSTSEC-2025-0141", # bincode (unmaintained), via transitive tooling
    "RUSTSEC-2020-0095", # difference (unmaintained), via a dev/test dep
    "RUSTSEC-2025-0134", # rustls-pemfile (unmaintained), via AWS SDK TLS
    "RUSTSEC-2026-0173", # proc-macro-error2 (unmaintained), via a macro dep

    # Two wasmtime advisories, both reached only through yara-x, which is the
    # only path to wasmtime in this graph (`cargo tree -i wasmtime`). yara-x
    # 1.19.0 declares `wasmtime = "43.0.2"` with `default-features = false` and
    # `features = ["cranelift", "runtime"]`, so 46.x is not reachable by bumping
    # anything we control and the feature set is the load-bearing fact for both
    # entries below. Waiting on yara-x in each case.
    #
    # Checked 2026-08-31: yara-x 1.20.0 does NOT help. It moves wasmtime to
    # 45.0.3, which every fixed range below also skips, with the same
    # default-features = false and the same two features. Bumping yara-x is
    # not the way out of either advisory; a wasmtime 46/47 line is.

    # RUSTSEC-2026-0222, "Stores can mix up type indices between engines"
    # (3.8 low, published 2026-07-31). Fixed in 24.0.12+, 36.0.13+, 46.0.2+ and
    # 47.0.3+, which skip the 43 line entirely.
    #
    # Not applicable as we run it. The precondition is a store crossing between
    # two wasmtime Engines, and production builds exactly one: scanning/mod.rs:505
    # calls yara::compile_rules_from_dir once while constructing the ScanEngine,
    # and every other yara_x::Compiler::new() in the tree sits under the
    # #[cfg(test)] at scanning/mod.rs:884. One engine for the process lifetime
    # means two engines never exist to confuse. THAT is the load-bearing claim
    # here: if a second compile ever lands in a production path, this ignore stops
    # being justified and has to be re-argued (see the note in scanning/yara.rs).
    #
    # Worth being precise about the blast radius rather than calling it isolated:
    # yara-x runs IN-PROCESS, in the server's address space (the ScanPipeline
    # holds the rules at scanning/mod.rs:429 and pushes the layer at :827).
    # What does bound it is that scanning happens on a dedicated worker pool off
    # the request path, a panic in a CPU layer is caught and converted to a
    # fail-closed scan_panic verdict rather than unwinding the worker, and the
    # CPU layers carry a wall-clock deadline. Defense in depth, not a sandbox.
    "RUSTSEC-2026-0222",

    # RUSTSEC-2026-0269, "Filesystem sandbox escape when paths or symlinks
    # contain trailing slashes" (8.8 high, published 2026-08-20). Fixed in
    # 24.0.13+, 36.0.14+, 46.0.3+ and 47.0.4+, which skip the 43 line entirely.
    # The high severity is real for anyone running WASI. We do not.
    #
    # Not applicable, and for a stronger reason than 0222: the vulnerable code is
    # not compiled. The bug is in wasmtime's WASI filesystem implementation, and
    # the filesystem sandbox it escapes only exists when WASI is built. yara-x
    # takes wasmtime with `default-features = false` and exactly two features,
    # `cranelift` and `runtime`, embedding it as a bare JIT to execute compiled
    # YARA rule bytecode. Nothing enables WASI, and the crates that implement it
    # are absent from Cargo.lock entirely:
    #
    #     wasmtime-wasi, wasi-common, cap-std, cap-primitives,
    #     cap-fs-ext, system-interface   -> none present
    #
    # THAT is the load-bearing claim: no WASI in the graph, so no filesystem
    # sandbox exists to escape. It is invalidated the moment any of those crates
    # appears in Cargo.lock, or yara-x enables a WASI feature, or we embed
    # wasmtime ourselves for anything. Re-argue it then rather than carrying it
    # forward. Guest wasm here is compiled YARA rules we produce from our own
    # rules directory, never attacker-supplied.
    "RUSTSEC-2026-0269",
]