This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.
stderrlog(5 total, 1 outdated, 2 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| atty | ^0.2.6 | 0.2.14 | up to date |
| chrono ⚠️ | ^0.4.10 | 0.4.38 | maybe insecure |
| log | ^0.4.11 | 0.4.22 | up to date |
| termcolor | ~1.1 | 1.4.1 | out of date |
| thread_local ⚠️ | ~1.1 | 1.1.8 | maybe insecure |
(5 total, 1 outdated)
| Crate | Required | Latest | Status |
|---|---|---|---|
| clap | ^3 | 4.5.20 | out of date |
| docopt | ^1.1 | 1.1.1 | up to date |
| libc | ^0.2.18 | 0.2.162 | up to date |
| serde | ^1.0 | 1.0.214 | up to date |
| structopt | ^0.3.20 | 0.3.26 | up to date |
chrono: Potential segfault in `localtime_r` invocationsUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.
No workarounds are known.
thread_local: Data race in `Iter` and `IterMut`In the affected version of this crate, {Iter, IterMut}::next used a weaker memory ordering when loading values than what was required, exposing a potential data race
when iterating over a ThreadLocal's values.
Crates using Iter::next, or IterMut::next are affected by this issue.