# 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-2024-0436", # paste (unmaintained), via proc-macro deps
    "RUSTSEC-2025-0134", # rustls-pemfile (unmaintained), via AWS SDK TLS
    "RUSTSEC-2026-0173", # proc-macro-error2 (unmaintained), via a macro dep

    # wasmtime 43.0.2, "Stores can mix up type indices between engines"
    # (3.8 low, published 2026-07-31), reached only through yara-x 1.19.0, which
    # is the current release and pins the 43 line. The fixed ranges are 24.0.12+,
    # 36.0.13+, 46.0.2+ and 47.0.3+ — they skip 43 entirely, so there is no
    # version reachable by bumping anything we control. Waiting on yara-x.
    #
    # Not applicable as we run it. The precondition is a store crossing between
    # two wasmtime Engines, and production builds exactly one: scanning/mod.rs:499
    # calls yara::compile_rules_from_dir once while constructing the ScanEngine,
    # and every other yara_x::Compiler::new() in the tree is under #[cfg(test)].
    # 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 (scanning/mod.rs:192).
    # 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.
    #
    # Monitoring: cargo-deny reports an unreachable ignore as
    # `advisory-not-detected`, so this entry announces its own obsolescence once
    # yara-x moves to a fixed wasmtime. Prune it then.
    "RUSTSEC-2026-0222",
]