cargo_audit
1 #!/usr/bin/env bash 2 # 3 # Run "cargo audit" with an appropriate set of flags. 4 5 set -euo pipefail 6 7 # List of vulnerabilities to ignore. It's risky to do this, so we should 8 # only do this when two circumstances hold: 9 # 1. The vulnerability doesn't affect us. 10 # 2. We can't update to an unaffected version. 11 # 3. We have a plan to not have this vulnerability ignored forever. 12 # 13 # If you add anything to this section, make sure to add a comment 14 # explaining why it's safe to do so. 15 IGNORE=( 16 # This is a real but theoretical unaligned read. It might happen only on 17 # Windows and only with a custom global allocator, which we don't do in our 18 # arti binary. The bad crate is depended on by env-logger. 19 # This is being discussed by those crates' contributors here: 20 # https://github.com/rust-cli/env_logger/pull/246 21 --ignore RUSTSEC-2021-0145 22 # As of 28 Nov 2023, all versions of the rsa crate have a variable 23 # timing attack that can leak private keys. 24 # 25 # We do not use (yet) do any private-key rsa operations in arti: 26 # we only use it to verify signatures. 27 --ignore RUSTSEC-2023-0071 28 # instant is unmaintained. 29 # 30 # This was fixed upstream in 31 # https://github.com/notify-rs/notify/pull/652 32 # but we're waiting for notify to cut a release. 33 # 34 # Ignoring while we are waiting for the notify version bump 35 --ignore RUSTSEC-2024-0384 36 ) 37 38 ${CARGO:-cargo} audit -D warnings "${IGNORE[@]}" 39 40 41 OBSOLETE_IGNORE=( 42 # This is not a vulnerability but an unmaintained warning for `ansi_term`. 43 # The upstream issue does not offer good alternatives, and anyway we get 44 # this crate via clap and tracing-*. 45 # It does not seem at all likely that this is really a problem for us. 46 --ignore RUSTSEC-2021-0139 47 # This is not a vulnerability but an unmaintained warn for the 48 # `net2` crate. It was pulled indirectly by `notify` 4.0. 49 # It's fixed in `notify` 5.0. 50 --ignore RUSTSEC-2020-0016 51 # This is not a vulnerability but an unmaintained warn for the 52 # `tempdir` crate. It was pulled by `tls-api` 0.7.0. `tls-api` 53 # 0.8.0 switched to tempfile instead. 54 --ignore RUSTSEC-2018-0017 55 # This is a vulnerability in the `nix` crate caused by an 56 # out-of-bounds write in `getgrouplist`. We got our `nix` 57 # dependency via `async-ctrlc`, which uses `ctrlc`, which uses 58 # `nix`. 59 # 60 # Why this didn't affect us: 61 # * ctrlc doesn't use `getgrouplist`. 62 # 63 # Why we couldn't update to a better version of `nix`: 64 # * ctrlc version 3.2.0 and earlier were stuck on `nix` 0.22. 65 # 66 # How it was fixed: 67 # * ctrlc version 3.2.1 upgraded its `nix` dependency to 0.23. 68 --ignore RUSTSEC-2021-0119 69 # This is a vulnerability in the `time` crate. We don't import 70 # `time` directly, but inherit it through the `oldtime` feature 71 # in `chrono`. The vulnerability occurs when somebody messes 72 # with the environment while at the same time calling a function 73 # that uses localtime_r. 74 # 75 # Why this doesn't affect us: 76 # * We never use the time crate, and we never mess with local times via the time crate. We only get the time crate accidentally 77 # because rusqlite builds chrono with its default-features 78 # enabled. 79 # 80 # Why we can't update to a better version of `time`: 81 # * Chrono's `oldtime` feature requires `time` 0.1.43, and can't 82 # be update to `time` 0.2.x. 83 # * Rusqlite's feature that enables `chrono` support does so by 84 # depending on `chrono` with default features, which includes 85 # `oldtime`. 86 # 87 # What we can do: 88 # * Get rusqlite to update its dependency on `chrono` to not 89 # include `oldtime`. 90 # (PR: https://github.com/rusqlite/rusqlite/pull/1031 ) 91 # * Stop using the `chrono` feature on rusqlite, and do our date 92 # conversions in `tor-dirmgr` manually. 93 # 94 # Eventual resolution: we migrated to use time 0.3 instead of chrono. 95 --ignore RUSTSEC-2020-0071 96 # This vulnerability affects the `chrono` crate: it uses 97 # `localtime_r()`, which is not thread-safe if anybody calls 98 # `setenv()`. 99 # 100 # This is concerning! What makes it not disastrous is: 101 # * We don't use chrono for any local times in Arti: only Utc. 102 # * We don't modify the environment. 103 # 104 # There is no unaffected version of chrono yet. 105 # 106 # Fortunately (?), the whole Rust ecosystem is currently freaking 107 # out about chrono, so we can hope there's a solution before too long. 108 # 109 # Eventual resolution: we migrated to use time 0.3 instead of chrono. 110 --ignore RUSTSEC-2020-0159 111 112 # The `users` crate (which `fs-mistrust` depended on) is unmaintained. 113 # 114 # Eventual resolution: we replaced `users` with `pwd-grp`. 115 --ignore RUSTSEC-2023-0040 116 117 # This is an API vulnerability in ed25519-dalek v1.x.x, to the 118 # extent that it does not force you to store private and public 119 # keys as a single keypair. 120 # 121 # We have desigend our APIs to work around this, and believe we 122 # are not affected. We should eventually upgrade to 123 # ed25519-dalek >= 2, however. 124 # 125 # Eventual resolution: We migrated to ed25519-dalek v2.x.x. 126 --ignore RUSTSEC-2022-0093 127 128 # This is not a vulnerability but an unmaintained warning for 129 # `generational-arena`. It is only used by arti-rpcserver (which is 130 # experimental). 131 # 132 # Eventual resolution: Migrated to slotmap-careful; see #1282 133 --ignore RUSTSEC-2024-0014 134 135 # proc-macro-error is unmaintained. 136 # 137 # Resolution: We migrated to dynasmrt 3, which doesn't use it. 138 --ignore RUSTSEC-2024-0370 139 140 # idns 0.5.0 and earlier had bugs in handling some punycode labels 141 # that can cause unequal labels to look like the same labels. 142 # 143 # See https://gitlab.torproject.org/tpo/core/arti/-/issues/1773 144 # for our internal tracking. 145 # 146 # Resolution: Upgraded to versions of hickory that don't need 147 # these versions of idns. 148 --ignore RUSTSEC-2024-0421 149 ) 150 _="${OBSOLETE_IGNORE[0]}"