Cryptographically verifiable, distributed dependency reviews
Add the last reviewed version to Cargo.toml / [dependencies]:
string-interner = "0.7.1"
Please, use mobile in landscape.
Filter reviews clicking on the numbers in the summary.
Full column names in tooltip hints: rating Negative, rating Neutral, rating Positive, rating Strong, thoroughness, understanding, reviews count.
I've found unsoundness and reported it: https://github.com/Robbepop/string-interner/issues/9.
This is use after free, but user cannot access that dangling pointer directly,
and invalid write access will not happen.
This issue is caused by StringInterner::clone()
followed by StringInterner::{get,get_or_intern}
,
so this would affect many use cases.
This is the reason of negative rating.
Except for that issue, there seems no problem.
unsafe
at line 125 is safe thanks to assert!
at the previous line.unsafe
at line 165 is safe because
InternalStrRef
s are immutable,*const str
referring inside private Vec<Box<str>>
, andInternalStrRef
s are not taken or copied to the outside of StringInterner
type.InternalStrRef
refers string owned by another interner instance,unsafe impl
s at line 233 and 239 is safe as commented in the source.
Vec<Box<str>>
is not changed until drop.InternalStrRef
and its content pointers are not exposed to the users.Once the UB bug is fixed, this crate would be safe.
© bestia.dev 2023, MIT License, Version: 2023.608.1636
Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/
EDIT: The found unsoundness is reported as vulnerability (RUSTSEC-2019-0023).
This is already fixed in 0.7.1, so you should use 0.7.1 or above.
I've found unsoundness and reported it: https://github.com/Robbepop/string-interner/issues/9.
This is use after free, but user cannot access that dangling pointer directly,
and invalid write access will not happen.
This issue is caused by
StringInterner::clone()
followed byStringInterner::{get,get_or_intern}
,so this would affect many use cases.
This is the reason of negative rating.
Except for that issue, there seems no problem.
unsafe
at line 125 is safe thanks toassert!
at the previous line.unsafe
at line 165 is safe becauseInternalStrRef
s are immutable,*const str
referring inside privateVec<Box<str>>
, andInternalStrRef
s are not taken or copied to the outside ofStringInterner
type.InternalStrRef
refers string owned by another interner instance,and it is reported as stated above.)
unsafe impl
s at line 233 and 239 is safe as commented in the source.Vec<Box<str>>
is not changed until drop.InternalStrRef
and its content pointers are not exposed to the users.Once the UB bug is fixed, this crate would be safe.