SliceDeque flagged as unsafe in 'cargo audit'

[LiquidityC]

Hello,

as explained in this issue: gnzlbg/slice_deque#90, depending on the crate SliceDeque will fail builds that run the cargo audit command.

Would it be possible to circumvent this dependency with VecDeque or similar since the maintainer of SliceDeque seems to be unresponsive? From my understanding VecDeque is Send so switching would also remove an unsafe impl in the codebase.

I could take a swing at this but for some reason I'm having problems building the project right now.

[germangb]

Problem with using VecDeque is that you cannot get a continuous slice of bytes from it without making an explicit call to VecDeque::make_contiguous first. I'm open to having VecDeque-backed storage under a feature flag, but if the security bug is impossible to trigger from minimp3, I'm not sure if I want it as the default.

Is there a way to patch the slice_deque crate?

[LiquidityC]

Looking at the very well defined issue in linked above, the problem does look like a trivial fix. It's the fact that the maintainer chose not to respond for over a month that makes me think he's busy with other things and not actively maintaining SliceDeque.

I can take a swing at fixing the actual issue. Otherwise we'll have to hope that someone takes up the mantel or forks the project and maintains it.

I'll try for a PR and see where we end up. I get that VecDeque isn't really a good option here.

[LiquidityC]

I sent a PR, gnzlbg/slice_deque#91. Let's see how it evolves.

[LiquidityC]

I gave up on waiting for the maintainer of SliceDeque. There is now a maintained fork here: https://crates.io/crates/slice-ring-buffer

Would you like a PR?