Sergey "Shnatsel" Davidoff

I've found some code that's unsound but doesn't pose a security issue and sent in a fix: https://github.com/rust-random/rand/issues/959

I've also managed to get rid of unsafe code in `&[u32]` to `u64` conversion by leaning into the optimizer: https://github.com/rust-random/rand/pull/963

Another small reduction: https://github.com/rust-random/rand/pull/962

I've looked into https://github.com/rust-random/rand/blob/05a1273ea83eeb0c0ade64ea55600b7f1fa39ec5/rand_core/src/block.rs#L352-L373 and it seems this `unsafe` cannot be removed without degrading performance and/or a major refactoring. But memory safety is just one of many guarantees this code...

MSRV bump from 1.32 to 1.34 should be harmless because even Debian Stable ships 1.34 by now.

Copying from https://github.com/rust-random/rand/issues/957: > Most unsafe code was removed in https://github.com/rust-random/rand/pull/1011 > > However, there is one use case remaining (fill_via_chunks) where we could not make the safe code as...

It also has a _ton_ of transitive dependencies with unsafe code in them. We should open an issue for auditing each of them.

Yeah, initializer sounds like it did not pan out. Some of the safety issues stem from the fact that [`read_to_end()`](https://doc.rust-lang.org/nightly/std/io/trait.Read.html#method.read_to_end) writes to a Vec and so does not require the...

`reqwest` is currently under a lot of churn due to transitioning to async/await, so let's postpone this one for now.

Undefined behavior in safe code described [here](https://www.reddit.com/r/rust/comments/ce09id/why_we_need_alternatives_to_actix/etxlqot/) ~~does not apply to actix-web: it's in actix-net crate, which is not in the dependency tree of actix-web. Still needs to be fixed...