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 console-subscriber

Dependencies

(17 total, 1 outdated, 3 possibly insecure)

CrateRequiredLatestStatus
 console-api^0.6.00.6.0up to date
 crossbeam-channel^0.50.5.12up to date
 crossbeam-utils^0.8.70.8.19up to date
 futures-task ⚠️^0.30.3.30maybe insecure
 hdrhistogram^7.3.07.5.4up to date
 humantime^2.1.02.1.0up to date
 parking_lot^0.120.12.2up to date
 prost-types^0.12.00.12.4up to date
 serde^11.0.198up to date
 serde_json^11.0.116up to date
 thread_local ⚠️^1.1.31.1.8maybe insecure
 tokio ⚠️^1.211.37.0maybe insecure
 tokio-stream^0.10.1.15up to date
 tonic^0.100.11.0out of date
 tracing^0.1.260.1.40up to date
 tracing-core^0.1.240.1.32up to date
 tracing-subscriber^0.3.170.3.18up to date

Dev dependencies

(3 total, 1 possibly insecure)

CrateRequiredLatestStatus
 futures^0.30.3.30up to date
 tokio ⚠️^1.211.37.0maybe insecure
 tower^0.40.4.13up to date

Security Vulnerabilities

futures-task: futures_task::waker may cause a use-after-free if used on a type that isn't 'static

RUSTSEC-2020-0060

Affected versions of the crate did not properly implement a 'static lifetime bound on the waker function. This resulted in a use-after-free if Waker::wake() is called after original data had been dropped.

The flaw was corrected by adding 'static lifetime bound to the data waker takes.

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.

tokio: reject_remote_clients Configuration corruption

RUSTSEC-2023-0001

On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as false.

This drops any intended explicit configuration for the reject_remote_clients that may have been set as true previously.

The default setting of reject_remote_clients is normally true meaning the default is also overridden as false.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);