#!/usr/bin/env bash
#
# Run "cargo audit" with an appropriate set of flags.

set -euo pipefail

# List of vulnerabilities to ignore.  It's risky to do this, so we should
# only do this when two circumstances hold:
#   1. The vulnerability doesn't affect us.
#   2. We can't update to an unaffected version.
#   3. We have a plan to not have this vulnerability ignored forever.
#
# If you add anything to this section, make sure to add a comment
# explaining why it's safe to do so.
IGNORE=(
    # This is a real but theoretical unaligned read.  It might happen only on
    # Windows and only with a custom global allocator, which we don't do in our
    # arti binary.  The bad crate is depended on by env-logger and clap.
    # This is being discussed by those crates' contributors here:
    #     https://github.com/clap-rs/clap/pull/4249
    #     https://github.com/rust-cli/env_logger/pull/246
    --ignore RUSTSEC-2021-0145
    # This is an API vulnerability in ed25519-dalek v1.x.x, to the
    # extent that it does not force you to store private and public
    # keys as a single keypair.
    #
    # We have desigend our APIs to work around this, and believe we
    # are not affected.  We should eventually upgrade to
    # ed25519-dalek >= 2, however.
    --ignore RUSTSEC-2022-0093
    # This is a DOS vulnerability against rustls-webpki (only some versions)
    # and webpki (all versions) where some cert chains can cause
    # ridiculous CPU usage.
    #
    # We've upgraded our rustls-webpki usage, but webpki (which is
    # unmaintained) is still used by tls-api, which we use from
    # arti-hyper.
    #
    # I've opened https://github.com/stepancheg/rust-tls-api/issues/45
    # for this issue, but I'm not sure whether `tls-api` is maintained.
    #
    # See https://gitlab.torproject.org/tpo/core/arti/-/issues/1016
    --ignore RUSTSEC-2023-0052
)

${CARGO:-cargo} audit -D warnings "${IGNORE[@]}"


OBSOLETE_IGNORE=(
    # This is not a vulnerability but an unmaintained warning for `ansi_term`.
    # The upstream issue does not offer good alternatives, and anyway we get
    # this crate via clap and tracing-*.
    # It does not seem at all likely that this is really a problem for us.
    --ignore RUSTSEC-2021-0139
    # This is not a vulnerability but an unmaintained warn for the
    # `net2` crate. It was pulled indirectly by `notify` 4.0.
    # It's fixed in `notify` 5.0.
    --ignore RUSTSEC-2020-0016
    # This is not a vulnerability but an unmaintained warn for the
    # `tempdir` crate. It was pulled by `tls-api` 0.7.0. `tls-api`
    # 0.8.0 switched to tempfile instead.
    --ignore RUSTSEC-2018-0017
    # This is a vulnerability in the `nix` crate caused by an
    # out-of-bounds write in `getgrouplist`.  We got our `nix`
    # dependency via `async-ctrlc`, which uses `ctrlc`, which uses
    # `nix`.
    #
    # Why this didn't affect us:
    #  * ctrlc doesn't use `getgrouplist`.
    #
    # Why we couldn't update to a better version of `nix`:
    #  * ctrlc version 3.2.0 and earlier were stuck on `nix` 0.22.
    #
    # How it was fixed:
    #  * ctrlc version 3.2.1 upgraded its `nix` dependency to 0.23.
    --ignore RUSTSEC-2021-0119
    # This is a vulnerability in the `time` crate.  We don't import
    # `time` directly, but inherit it through the `oldtime` feature
    # in `chrono`.  The vulnerability occurs when somebody messes
    # with the environment while at the same time calling a function
    # that uses localtime_r.
    #
    # Why this doesn't affect us:
    #   * We never use the time crate, and we never mess with local times via the time crate.  We only get the time crate accidentally
    #     because rusqlite builds chrono with its default-features
    #     enabled.
    #
    # Why we can't update to a better version of `time`:
    #   * Chrono's `oldtime` feature requires `time` 0.1.43, and can't
    #     be update to `time` 0.2.x.
    #   * Rusqlite's feature that enables `chrono` support does so by
    #     depending on `chrono` with default features, which includes
    #     `oldtime`.
    #
    # What we can do:
    #  * Get rusqlite to update its dependency on `chrono` to not
    #    include `oldtime`.
    #    (PR: https://github.com/rusqlite/rusqlite/pull/1031 )
    #  * Stop using the `chrono` feature on rusqlite, and do our date
    #    conversions in `tor-dirmgr` manually.
    #
    # Eventual resolution: we migrated to use time 0.3 instead of chrono.
    --ignore RUSTSEC-2020-0071
    # This vulnerability affects the `chrono` crate: it uses
    # `localtime_r()`, which is not thread-safe if anybody calls
    # `setenv()`.
    #
    # This is concerning!  What makes it not disastrous is:
    #  * We don't use chrono for any local times in Arti: only Utc.
    #  * We don't modify the environment.
    #
    # There is no unaffected version of chrono yet.
    #
    # Fortunately (?), the whole Rust ecosystem is currently freaking
    # out about chrono, so we can hope there's a solution before too long.
    #
    # Eventual resolution: we migrated to use time 0.3 instead of chrono.
    --ignore RUSTSEC-2020-0159
)
_="${OBSOLETE_IGNORE[0]}"