I've sent some patches and read whole sources carefully.
Data structure used by this crate is simple enough.
Additionally it contains many assertions and has no unsafe code.

I'm not clear it is safe, but at least it does not seem malicious.

Potential unsoundness is reported at https://github.com/khuey/lazy-init/issues/9 but it is neither fixed nor refuted.
This is the reason of the neutral rating.

It is completely written in safe Rust, and I didn't find any malicious code.

I've found a minor issue and a non-obvious behavior which is not documented (yet), but I think they are not severe and they have very easy workarounds.
You can see https://github.com/RazrFalcon/rctree/issues if you want to know them.

In conclusion, I think this crate is safe to use.

This crate contains a single unsafe block and it seems ok.

I have reviewed the previous version (0.7.0) and sent some patches to make the crate safer.

In this version, I found no security problems and no malicious code.

• unsafe at line 158 is safe because
  • both InternalStrRefs and strings referred by them are immutable,
  • strings referred by InternalStrRefs won't be dropped until the owning interner is dropped,
  • they have *const str referring inside private Vec<Box<str>> which is owned by the same interner, and
  • InternalStrRefs are not taken or copied to the outside of StringInterner type.
• unsafe impls at line 248 and 254 is safe as commented in the source.
  • Addresses of strings in Vec<Box<str>> is not changed until the owning interner is dropped.
  • InternalStrRefs and their content pointers are not exposed to the users.
  • Pointers to the strings are read-only.

I think this crate is safe to use.

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 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
  • InternalStrRefs are immutable,
  • they have *const str referring inside private Vec<Box<str>>, and
  • InternalStrRefs are not taken or copied to the outside of StringInterner type.
  • (It is unsafe that InternalStrRef refers string owned by another interner instance,
    and it is reported as stated above.)
• unsafe impls at line 233 and 239 is safe as commented in the source.
  • Addresses of strings in Vec<Box<str>> is not changed until drop.
  • InternalStrRef and its content pointers are not exposed to the users.
  • Pointers to the strings are read-only.

Once the UB bug is fixed, this crate would be safe.

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
  • InternalStrRefs are immutable,
  • they have *const str referring inside private Vec<Box<str>>, and
  • InternalStrRefs are not taken or copied to the outside of StringInterner type.
  • (It is unsafe that InternalStrRef refers string owned by another interner instance,
    and it is reported as stated above.)
• unsafe impls at line 233 and 239 is safe as commented in the source.
  • Addresses of strings in Vec<Box<str>> is not changed until drop.
  • InternalStrRef and its content pointers are not exposed to the users.
  • Pointers to the strings are read-only.

Once the UB bug is fixed, this crate would be safe.