arti/maint/cargo_audit

103 lines
4.3 KiB
Bash
Executable File

#!/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
# The `users` crate (which `fs-mistrust` depends on) is unmaintained.
# Ignore the advisory until we figure out what to replace it with (arti#877)
--ignore RUSTSEC-2023-0040
)
${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]}"