Brian Smith

> So after my attempt in [rust-lang/libc#1244](https://github.com/rust-lang/libc/pull/1244) and a later attempt in [rust-lang/libc#1285](https://github.com/rust-lang/libc/pull/1285), the conclusion was to keep `cty` and `libc` separate for now ([rust-lang/libc#1285 (comment)](https://github.com/rust-lang/libc/pull/1285#issuecomment-467085692)), but to make sure...

> Also, @briansmith is there a reason we don't just use [`getrandom`](https://github.com/rust-random/getrandom) *ring*'s doesn't use `getrandom` primarily because: (1) *ring* predates that crate by several years, (2) *ring* avoids depending...

I submitted PR #840 as a stepping stone to resolving the libc types issue in the interim until the Rust libs team can agree on a long-term solution.

One particular kind of `no_std` environment is a freestanding environment as defined by ISO C. PR #842 makes one step towards supporting freestanding environments by removing the dependencies on `string.h`....

Please take a look at PR #869, which makes libstd an optional dependency even for RSA and the test framework in favor of using `alloc`.

Regarding the libc dependency, please see PR #39. Basically we just need to write a little `#[cfg(...)]` code to decide whether `c_int` and `c_uint` are 32 bits or 64 bits....

PR #875 avoids `#include ` in release builds. This means release builds do not (AFAICT) attempt to use any headers that aren't guaranteed to be present in a freestanding implementation....

PR #879 will remove the `libc` crate dependency for most platforms.

"In particular, our end-to-end exploit can leak the entire private key of a secure enclave running on a separate CPU core after only a single digital signature operation." - https://www.vusec.net/projects/crosstalk/

https://software.intel.com/security-software-guidance/insights/deep-dive-special-register-buffer-data-sampling