1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
#!/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.
# This is being discussed by those crates' contributors here:
# https://github.com/rust-cli/env_logger/pull/246
--ignore RUSTSEC-2021-0145
# As of 28 Nov 2023, all versions of the rsa crate have a variable
# timing attack that can leak private keys.
#
# We do not use (yet) do any private-key rsa operations in arti:
# we only use it to verify signatures.
--ignore RUSTSEC-2023-0071
# instant is unmaintained.
#
# This was fixed upstream in
# https://github.com/notify-rs/notify/pull/652
# but we're waiting for notify to cut a release.
#
# Ignoring while we are waiting for the notify version bump
--ignore RUSTSEC-2024-0384
# idns 0.5.0 and earlier is used by hickory-proto:
# https://github.com/hickory-dns/hickory-dns/issues/2661
#
# These versions have bugs in handling some punycode labels
# that can cause unequal labels to look like the same labels.
#
# See https://gitlab.torproject.org/tpo/core/arti/-/issues/1773
# for our internal tracking.
--ignore RUSTSEC-2024-0421
)
${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
# The `users` crate (which `fs-mistrust` depended on) is unmaintained.
#
# Eventual resolution: we replaced `users` with `pwd-grp`.
--ignore RUSTSEC-2023-0040
# 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.
#
# Eventual resolution: We migrated to ed25519-dalek v2.x.x.
--ignore RUSTSEC-2022-0093
# This is not a vulnerability but an unmaintained warning for
# `generational-arena`. It is only used by arti-rpcserver (which is
# experimental).
#
# Eventual resolution: Migrated to slotmap-careful; see #1282
--ignore RUSTSEC-2024-0014
# proc-macro-error is unmaintained.
#
# Resolution: We migrated to dynasmrt 3, which doesn't use it.
--ignore RUSTSEC-2024-0370
)
_="${OBSOLETE_IGNORE[0]}"
|
