Are the wildcard version ranges updated when fixes are available ?

[sbs2001]

The title pretty much sums it up.

For eg at https://github.com/RustSec/advisory-db/blob/main/crates/parse_duration/RUSTSEC-2021-0041.md if a fix is released in future, then the current data here would be misleading.

A safer approach IMHO is to have ranges with both lower and upper bounds, since version histories are mostly non linear.

For eg
package foo could have versions 1.0.0, 2.0.0 . Then a vulnerability is found, as a fix and to retain backward compatibility the maintainers release 1.1.0, 2.1.0. So version ranges like is_vulnerable = '<=2.0.0' are clearly misleading as time passes.

[tarcieri]

Version ranges are kind of an electric third rail of this project.

If you look at #827 there was a ton of discussion about what to do about the version ranges. For this particular case it probably doesn't matter a whole lot in practice, as the crate seems unmaintained and we should probably file an unmaintained crate notice:

zeta12ti/parse_duration#21

We didn't used to support wildcard versions at all, actually. They were "accidentally" reintroduced as part of updating the semver crate:

https://github.com/RustSec/rustsec-crate/pull/217

Additional background:

• Wrong vulnerability detection rustsec#17
• Handling of pre-release versions rustsec#30
• Bug: Pre-release versions not considered matching dtolnay/semver#172

We will be looking into a more comprehensive fix for this issue, sort of along the lines you're describing, but probably drawing more directly from Google OSV.

In the meantime though this is a complicated issue and nobody presently has the time to address it more thoroughly.