fast-able possible unsound public API

[charlesxsh]

Cannot find a way to create PR/issue over the upstream project, so I cannot reference a link to this report.

[fintelia]

I don't think there's actually a soundness bug here. [Edit: as of the latest version]

The reason is a bit silly: the src/vec.rs file isn't actually used when building the crate. Instead, the relevant mod statement uses a #[path] attribute to replace the path with src/vec2.rs. I can't speak for the soundness of the overall crate, but you can see the real implementation of SyncVec::get_uncheck doesn't have an unsafe block.

[charlesxsh]

I don't think there's actually a soundness bug here.

The reason is a bit silly: the src/vec.rs file isn't actually used when building the crate. Instead, the relevant mod statement uses a #[path] attribute to replace the path with src/vec2.rs. I can't speak for the soundness of the overall crate, but you can see the real implementation of SyncVec::get_uncheck doesn't have an unsafe block.

Oh I should add more details. The version of the crate to have this issue is 1.11.7. Link: https://docs.rs/crate/fast-able/1.11.7/source/src/vec.rs. Would you verify does this version of code align with the description? If yes, I will add the detail version info.

[fintelia]

Ah, version 1.11.7 does seem to be vulnerable. A quick way to check is to go to the docs.rs page for a specific version and click the "source" link on SyncVec::get_uncheck

[charlesxsh]

Ah, version 1.11.7 does seem to be vulnerable. A quick way to check is to go to the docs.rs page for a specific version and click the "source" link on SyncVec::get_uncheck

Sounds good. I will add this detail to md file

[djc]

@guoyucode we'd like to publish an advisory this -- is that okay with you?