Remove nightly recommendation now that subtle has stable opt barriers.

This bumps the required `subtle` version to `2.2.1`, which contains those changes.
This commit is contained in:
Henry de Valence 2019-11-15 14:29:14 -08:00
parent 77203aa1cb
commit 2b51978553
2 changed files with 8 additions and 8 deletions

View file

@ -39,7 +39,7 @@ harness = false
rand_core = { version = "0.5", default-features = false }
byteorder = { version = "^1.2.3", default-features = false, features = ["i128"] }
digest = { version = "0.8", default-features = false }
subtle = { version = "2", default-features = false }
subtle = { version = "^2.2.1", default-features = false }
serde = { version = "1.0", default-features = false, optional = true, features = ["derive"] }
packed_simd = { version = "0.3", features = ["into_bits"], optional = true }
zeroize = { version = "1", default-features = false }

View file

@ -63,7 +63,8 @@ See `CHANGELOG.md` for more details.
# Backends and Features
The `nightly` feature enables features available only when using a Rust nightly
compiler. **It is recommended for security**.
compiler. In particular, it is required for rendering documentation and for
the SIMD backends.
Curve arithmetic is implemented using one of the following backends:
@ -103,11 +104,10 @@ unless specifically marked as being variable-time code.
We believe that our constant-time logic is lowered to constant-time
assembly, at least on `x86_64` targets.
As an additional guard against possible future compiler optimizations, the
`nightly` feature places an optimization barrier before every
As an additional guard against possible future compiler optimizations,
the `subtle` crate places an optimization barrier before every
conditional move or assignment. More details can be found in [the
documentation for the `subtle` crate][subtle_doc]. This is
recommended, but not required.
documentation for the `subtle` crate][subtle_doc].
Some functionality (e.g., multiscalar multiplication or batch
inversion) requires heap allocation for temporary buffers. All
@ -124,9 +124,9 @@ functions in other crates.
The implementation is memory-safe, and contains no significant
`unsafe` code. The SIMD backend uses `unsafe` internally to call SIMD
intrinsics. These are marked `unsafe` because invoking them on an
intrinsics. These are marked `unsafe` only because invoking them on an
inappropriate CPU would cause `SIGILL`, but the entire backend is only
compiled with appropriate `target_feature`s.
compiled with appropriate `target_feature`s, so this cannot occur.
# Performance