Cargo.toml specifies some overly strict version ranges:
|
[dependencies] |
|
base64 = { version=">=0.10.1, <0.14" } |
|
bytes = { version=">=1.0.0, <1.1.0" } |
|
http = { version=">=0.2.2, <0.3" } |
|
httpdate = { version=">=0.3.2, <0.4" } |
|
httparse = { version=">=1.0, <1.4" } |
|
language-tags = { version=">=0.2, <0.3" } |
|
mime = { version=">=0.3.2, <0.4" } |
|
percent-encoding = { version=">=2.1.0, <2.2" } |
|
unicase = { version=">=2.6.0, <2.7" } |
This results in some really bizarre behaviors for users of hyperx, like packages getting downgraded when hyperx is pulled in. I'd like to pull this package into a crate I'm working on, to move it off an ancient version of hyper, but the odd range here causes an (not as, but still) old version of hyper to get pulled in. Both are under a RUSTSEC vuln, which is why I'd like to move the crate to hyperx.
Just set these equal to, e.g.,
where they span only part of a single semver compatibility range? This lets Cargo do the right thing, and pull in bug/security fixes as it can.
(Note though, that this doesn't apply to base64, b/c there the range is allowing multiple semver-incompatible versions.)
Cargo.tomlspecifies some overly strict version ranges:hyperx/Cargo.toml
Lines 23 to 32 in 58d9a6d
This results in some really bizarre behaviors for users of
hyperx, like packages getting downgraded whenhyperxis pulled in. I'd like to pull this package into a crate I'm working on, to move it off an ancient version ofhyper, but the odd range here causes an (not as, but still) old version ofhyperto get pulled in. Both are under a RUSTSEC vuln, which is why I'd like to move the crate tohyperx.Just set these equal to, e.g.,
where they span only part of a single semver compatibility range? This lets Cargo do the right thing, and pull in bug/security fixes as it can.
(Note though, that this doesn't apply to
base64, b/c there the range is allowing multiple semver-incompatible versions.)