103 lines
4.3 KiB
Bash
Executable File
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]}"
|