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 tlfs

Dependencies

(14 total, 6 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 anyhow^1.0.511.0.82up to date
 async-trait^0.1.520.1.80up to date
 bytecheck^0.6.70.7.0out of date
 ed25519-dalek ⚠️^1.0.12.1.1out of date
 fnv^1.0.71.0.7up to date
 futures^0.3.170.3.30up to date
 libp2p-broadcast^0.7.00.12.0out of date
 libp2p-webrtc^0.2.10.3.0out of date
 log-panics^2.0.02.1.0up to date
 rkyv^0.7.260.7.44up to date
 tracing^0.1.290.1.40up to date
 tracing-log^0.1.20.2.0out of date
 tracing-subscriber^0.3.30.3.18up to date
 libp2p ⚠️^0.42.00.53.2out of date

Dev dependencies

(1 total, all up-to-date)

CrateRequiredLatestStatus
 async-std^1.10.01.12.0up to date

Crate tlfs-crdt

Dependencies

(14 total, 4 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 anyhow^1.0.511.0.82up to date
 base64^0.13.00.22.0out of date
 blake3^1.2.01.5.1up to date
 bytecheck^0.6.70.7.0out of date
 crepe^0.1.50.1.8up to date
 ed25519-dalek ⚠️^1.0.12.1.1out of date
 futures^0.3.170.3.30up to date
 getrandom^0.2.30.2.14up to date
 hex^0.4.30.4.3up to date
 parking_lot^0.11.20.12.2out of date
 rkyv^0.7.260.7.44up to date
 smallvec^1.7.01.13.2up to date
 tracing^0.1.290.1.40up to date
 vec-collections^0.4.30.4.3up to date

Dev dependencies

(5 total, 1 outdated)

CrateRequiredLatestStatus
 async-std^1.10.01.12.0up to date
 log-panics^2.0.02.1.0up to date
 proptest^1.0.01.4.0up to date
 tracing-log^0.1.20.2.0out of date
 tracing-subscriber^0.3.30.3.18up to date

Crate tlfs-api

Dependencies

(4 total, all up-to-date)

CrateRequiredLatestStatus
 anyhow^1.0.511.0.82up to date
 ffi-gen^0.1.50.1.13up to date
 ffi-gen-macro^0.1.20.1.2up to date
 futures^0.3.170.3.30up to date

Build dependencies

(1 total, all up-to-date)

CrateRequiredLatestStatus
 ffi-gen^0.1.50.1.13up to date

Crate relay

Dependencies

(10 total, 4 outdated, 3 possibly insecure)

CrateRequiredLatestStatus
 acme-lib^0.8.20.9.1out of date
 anyhow^1.0.511.0.82up to date
 clap^3.0.0-rc.44.5.4out of date
 hex^0.4.30.4.3up to date
 libp2p ⚠️^0.41.00.53.2out of date
 rustls-pemfile^0.2.12.1.2out of date
 tokio ⚠️^1.14.01.37.0maybe insecure
 tracing^0.1.290.1.40up to date
 tracing-subscriber^0.3.30.3.18up to date
 warp ⚠️^0.3.20.3.7maybe insecure

Crate tlfsc

Dependencies

(5 total, 1 outdated)

CrateRequiredLatestStatus
 anyhow^1.0.511.0.82up to date
 clap^3.0.0-rc.44.5.4out of date
 fnv^1.0.71.0.7up to date
 pest^2.1.32.7.9up to date
 pest_derive^2.1.02.7.9up to date

Security Vulnerabilities

warp: Improper validation of Windows paths could lead to directory traversal attack

RUSTSEC-2022-0082

Path resolution in warp::filters::fs::dir didn't correctly validate Windows paths meaning paths like /foo/bar/c:/windows/web/screen/img101.png would be allowed and respond with the contents of c:/windows/web/screen/img101.png. Thus users could potentially read files anywhere on the filesystem.

This only impacts Windows. Linux and other unix likes are not impacted by this.

libp2p: libp2p Lack of resource management DoS

RUSTSEC-2022-0084

libp2p allows a potential attacker to cause victim p2p node to run out of memory

The out of memory failure can cause crashes where libp2p is intended to be used within large scale networks leading to potential Denial of Service (DoS) vector

Users should upgrade or reference the DoS mitigation strategies.

ed25519-dalek: Double Public Key Signing Function Oracle Attack on `ed25519-dalek`

RUSTSEC-2022-0093

Versions of ed25519-dalek prior to v2.0 model private and public keys as separate types which can be assembled into a Keypair, and also provide APIs for serializing and deserializing 64-byte private/public keypairs.

Such APIs and serializations are inherently unsafe as the public key is one of the inputs used in the deterministic computation of the S part of the signature, but not in the R value. An adversary could somehow use the signing function as an oracle that allows arbitrary public keys as input can obtain two signatures for the same message sharing the same R and only differ on the S part.

Unfortunately, when this happens, one can easily extract the private key.

Revised public APIs in v2.0 of ed25519-dalek do NOT allow a decoupled private/public keypair as signing input, except as part of specially labeled "hazmat" APIs which are clearly labeled as being dangerous if misused.

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);