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 s2gpp

Dependencies

(27 total, 15 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 actix=0.12.00.13.5out of date
 actix-broker^0.4.10.4.4up to date
 actix-telepathy=0.4.10.6.1out of date
 anyhow^1.0.411.0.98up to date
 console^0.15.00.16.0out of date
 csv^1.1.61.3.1up to date
 env_logger^0.9.00.11.8out of date
 futures-sink^0.3.210.3.31up to date
 indexmap^1.82.10.0out of date
 indicatif^0.16.20.17.12out of date
 itertools^0.10.30.14.0out of date
 kdtree^0.6.00.7.0out of date
 log^0.40.4.27up to date
 meanshift-rs^0.8.00.9.3out of date
 ndarray^0.150.16.1out of date
 ndarray-linalg^0.140.17.0out of date
 ndarray-stats^0.50.6.0out of date
 ndarray_einsum_beta^0.7.00.7.0up to date
 num-integer^0.1.440.1.46up to date
 num-traits^0.2.140.2.19up to date
 numpy^0.160.25.0out of date
 pyo3 ⚠️^0.160.25.1out of date
 serde^1.01.0.219up to date
 serde_with^1.9.13.14.0out of date
 sortedvec^0.5.00.5.0up to date
 structopt^0.30.3.26up to date
 tokio ⚠️^1.121.46.0maybe insecure

Dev dependencies

(3 total, all up-to-date)

CrateRequiredLatestStatus
 actix-rt^2.2.02.10.0up to date
 port_scanner^0.1.50.1.5up to date
 rayon^1.5.01.10.0up to date

Security Vulnerabilities

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

pyo3: Risk of buffer overflow in `PyString::from_object`

RUSTSEC-2025-0020

PyString::from_object took &str arguments and forwarded them directly to the Python C API without checking for terminating nul bytes. This could lead the Python interpreter to read beyond the end of the &str data and potentially leak contents of the out-of-bounds read (by raising a Python exception containing a copy of the data including the overflow).

In PyO3 0.24.1 this function will now allocate a CString to guarantee a terminating nul bytes. PyO3 0.25 will likely offer an alternative API which takes &CStr arguments.