The `zeroize` crate defines a blanket impl of `Zeroize` for any type
with the `DefaultIsZeroes` marker trait, which replaces the value with
its `Default` using volatile writes with a memory fence.
This does require defining `Default` on `Sign`, but it seems like
`Sign::NoSign` is a fairly reasonable choice for a default.
The `zeroize_derive` crate has quite a few dependencies, and in
particular `syn` is a fairly large one with not-insignificant compile
times.
The usages of `zeroize` are fairly trivial with two impls zeroing a
total of three fields, which makes them easy to write by hand.
It takes more crate dependencies for the proc macro to do that
(`proc-macro2`, `quote`, `syn`, `synstructure`, and `zeroize_derive`
itself) than there are fields being zeroized, so I think it makes sense
to ditch the additional dependencies and write these impls by hand.
Upgrades the edition, with changes primarily performed by
`cargo fix --edition`.
In order to keep the changes to a minimum, this doesn't include
automated idiom fixes (i.e. `cargo fix --edition-idioms`).
This is needed to unblock the edition upgrade for the RSA crate:
https://github.com/RustCrypto/RSA/pull/135
Motivation: [autocfg panics when building with `-Zbuild-std`][1].
Instead of panicking when the `i128` feature is requested but
`probe_type("i128")` fails, just go ahead and enable the feature. If
`i128` truly isn't available then compilation will still fail, just
later on. This is unlikely to be an issue in practice since [`i128`
was stabilized in Rust 1.26.0][2].
Tested by building with:
cargo +nightly build --target=x86_64-unknown-uefi \
-Zbuild-std=core,alloc --no-default-features \
--features=i128
[1]: https://github.com/cuviper/autocfg/issues/34
[2]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1260-2018-05-10
* no_std support
* Use integer log2 when possible to estimate allocations
* Remove std features from a few dependencies
* Use libm for missing funcs in nostd environment
* Use autocfg to detect presence of i128
* Better CI test for nostd environment
* Move benchmark to a separate crate
* Make the tests pass in no_std builds
* Use thumbv7m target for nostd build test
* Add documentation about the no-std compatibility
* Make zeroize and prime features no_std-compatible
* Test each feature in nostd context
* Fix mac test to work in no_std environment
* Avoid using thread_rng in nostd tests
* Fix prime tests in nostd mode
* Fix all warnings and errors
* Only test nostd builds on nightly on travis
* Travis: Only do nostd builds on nightly