wavefront_obj dependency is unmaintained and pulls in dependencies with soundness issues

[eric-seppanen]

Running cargo deny check dependencies on a project that includes three-d-asset with the obj feature displays the following alert.

ID: RUSTSEC-2023-0055
Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0055
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.
Solution: No safe upgrade is available!

lexical v5.2.2
└── wavefront_obj v10.0.0
    └── three-d-asset v0.5.0
        └── three-d v0.15.0

[asny]

If you have an alternative to wavefront_obj, you're more than welcome to change that dependency.

[eric-seppanen]

@asny closed this as completed

Apologies; can you clarify why this was closed? Does that mean this issue won't be fixed?

If that's the case, then perhaps I could ask you to close this issue as "not planned" so others don't get the impression the problem was resolved.

[asny]

This is a problem in wavefront_obj, not in this crate, please open an issue there instead. Also, I don't understand the problem, do you have issues loading an obj file? Finally, you can disable the obj feature if you don't like that dependency.

[eric-seppanen]

wavefront_obj appears to be unmaintained.

If a dependency has unsoundness bugs (i.e. undefined behavior), that can break code throughout the project, and the damage is not limited to the functions or modules with the bugs. Any project including that dependency may have unpredictable bugs. It's probably unwise to depend on crates that have soundness bugs (or have dependencies with soundness bugs) that are never going to be fixed (because the crate is abandoned). "Seems to work" is not a reliable guarantee-- there are lots of discussions of undefined behavior that talk about this in more detail.

There are a few ways to resolve this, though they may not be attractive:

1. Drop the dependency on wavefront_obj and lose support for the obj format.
2. Drop the dependency on wavefront_obj and replace it with some other crate that can do the same job.
3. Fork the wavefront_obj crate and fix its issues.

There is no way to communicate to a downstream user that enabling the obj feature exposes them to soundness bugs. I only noticed this because of the work of the RustSec project and cargo deny reporting the problem.