RUSTSEC-2023-0055: Multiple soundness issues

[github-actions[bot]]

trafficstars

Multiple soundness issues

Details
Status	unsound
Package	lexical
Version	6.1.1
URL
Date	2023-09-03

lexical contains multiple soundness issues:

1. Bytes::read() allows creating instances of types with invalid bit patterns
2. BytesIter::read() advances iterators out of bounds
3. The BytesIter trait has safety invariants but is public and not marked unsafe
4. write_float() calls MaybeUninit::assume_init() on uninitialized data, which is is not allowed by the Rust abstract machine

The crate also has some correctness issues and appears to be unmaintained.

Alternatives

For quickly parsing floating-point numbers third-party crates are no longer needed. A fast float parsing algorith by the author of lexical has been merged into libcore.

For quickly parsing integers, consider atoi and btoi crates (100% safe code). atoi_radix10 provides even faster parsing, but only with -C target-cpu=native, and at the cost of some unsafe.

For formatting integers in a #[no_std] context consider the numtoa crate.

For working with big numbers consider num-bigint and num-traits.

See advisory page for additional details.

[tannaurus]

This appears to have silenced in main https://github.com/sigstore/sigstore-rs/pull/387/files

This that a temporary solution, do we plan on monitoring this further?

A new warning has taken its place: https://rustsec.org/advisories/RUSTSEC-2023-0086

[flavio]

I've created https://github.com/timothee-haudebourg/json-number/pull/6 that addresses both issues.

[flavio]

The upstream maintainer hasn't provided any feedback to the PR. There's also another PR that was created with the same purpose. No updates :cry:

I've also sent a mail to the maintainer, but I didn't get any response.

I wonder how we should proceed

[reneleonhardt]

https://github.com/timothee-haudebourg/json-number/pull/5 with lexical 7.0.1 has been merged and tagged as 0.4.9, can this issue be closed?

The relaxed dependency PR has not been tagged but that should not be necessary as there is no outdated Cargo.lock.

[flavio]

True, this can now be closed.

I've also created https://github.com/sigstore/sigstore-rs/pull/489 to not hide this error from cargo audit