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.

Crate stderrlog

Dependencies

(5 total, 2 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 atty^0.2, <=0.2.110.2.14out of date
 chrono ⚠️^0.40.4.38maybe insecure
 log^0.4.10.4.22up to date
 termcolor^1.01.4.1up to date
 thread_local ⚠️^0.3, <=0.3.41.1.8out of date

Dev dependencies

(5 total, 3 outdated, 1 insecure)

CrateRequiredLatestStatus
 clap~2.22.04.5.20out of date
 docopt^0.61.1.1out of date
 libc^0.20.2.161up to date
 rustc-serialize ⚠️^0.30.3.25insecure
 structopt^0.20.3.26out of date

Security Vulnerabilities

chrono: Potential segfault in `localtime_r` invocations

RUSTSEC-2020-0159

Impact

Unix-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.

Workarounds

No workarounds are known.

References

rustc-serialize: Stack overflow in rustc_serialize when parsing deeply nested JSON

RUSTSEC-2022-0004

When parsing JSON using json::Json::from_str, there is no limit to the depth of the stack, therefore deeply nested objects can cause a stack overflow, which aborts the process.

Example code that triggers the vulnerability is

fn main() {
    let _ = rustc_serialize::json::Json::from_str(&"[0,[".repeat(10000));
}

serde is recommended as a replacement to rustc_serialize.

thread_local: Data race in `Iter` and `IterMut`

RUSTSEC-2022-0006

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.