This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate hyper

Dependencies

(17 total, 1 outdated, 1 insecure)

CrateRequiredLatestStatus
 bytes^11.0.1up to date
 futures-channel^0.30.3.14up to date
 futures-core^0.30.3.14up to date
 futures-util^0.30.3.14insecure
 h2^0.30.3.2up to date
 http^0.20.2.4up to date
 http-body^0.40.4.1up to date
 httparse^1.01.4.0up to date
 httpdate^0.31.0.0out of date
 itoa^0.4.10.4.7up to date
 libc^0.20.2.93up to date
 pin-project^1.01.0.7up to date
 socket2^0.40.4.0up to date
 tokio^11.5.0up to date
 tower-service^0.30.3.1up to date
 tracing^0.10.1.25up to date
 want^0.30.3.0up to date

Dev dependencies

(15 total, 1 insecure)

CrateRequiredLatestStatus
 futures-util^0.30.3.14insecure
 matches^0.10.1.8up to date
 num_cpus^1.01.13.0up to date
 pretty_env_logger^0.40.4.0up to date
 serde^1.01.0.125up to date
 serde_derive^1.01.0.125up to date
 serde_json^1.01.0.64up to date
 spmc^0.30.3.0up to date
 tokio^11.5.0up to date
 tokio-test^0.40.4.1up to date
 tokio-util^0.60.6.6up to date
 tower^0.40.4.6up to date
 tower-util^0.30.3.1up to date
 url^2.22.2.1up to date
 pnet_datalink^0.27.20.27.2up to date

Security Vulnerabilities

futures-util: MutexGuard::map can cause a data race in safe code

RUSTSEC-2020-0059

Affected versions of the crate had a Send/Sync implementation for MappedMutexGuard that only considered variance on T, while MappedMutexGuard dereferenced to U.

This could of led to data races in safe Rust code when a closure used in MutexGuard::map() returns U that is unrelated to T.

The issue was fixed by fixing Send and Sync implementations, and by adding a PhantomData<&'a mut U> marker to the MappedMutexGuard type to tell the compiler that the guard is over U too.