Brian Smith

I decided not to do any, but instead leave it up to ring-ffi to do it. See https://github.com/briansmith/ring-ffi/issues/3.

> Can this be reopened? I've had users ask me whether I could do this: [est31/rcgen#47](https://github.com/est31/rcgen/issues/47) Sure.

Destructor/drop-based zeroization as people intuitively think about it has limited value because it's impractical to use an allowlist-type approach to make sure every sensitive thing is zeroized. Instead it would...

BTW, in case people are interested in why I'm suggesting we add Kyber and ignoring all the other algorithms: Some people said they could help review PRs and help with...

> (I tried running cargo test --no-default-features but that doesn't seem to run on main or my branch?). That is fixed by #1652.

Also, I propose that public API exposed from *ring* only exposes the hybrid versions, and only the hybrids that are actually deployed on the web. My understanding is that there...

Closing this since we do support s390x now. I understand that in some ways this is a better approach since it enables the optimized assembly language code for s390x. However,...

Contrasting with what I wrote earlier, I would OK with exposing Kyber directly in a no-hybrid fashion. In the short term, the main priority should be choosing an implementation that...

OTOH, we are also trying to remove dev-dependencies from the *ring* crate so that people can do `cargo test -p ring` to run the tests...so maybe we need a different...

For what we're doing right now, we actually wouldn't need the ring-c-test crate to be a dev-dependency of the ring crate; as long as they use the same build.rs they...