rust-random/rand#1697 which updates `rand_core` to v0.10.0-rc-3 for the
`rand` crate has been merged.
This removes `patch.crates-io` for `getrandom` and pins to the merged
commit revision for `rand`, as well as bumping the `getrandom`
dependency of `x25519-dalek` to v0.4.0-rc.0.
Most of the changes in this PR are actually from the associated `rand`
crate updates which are happening in rust-random/rand#1697, notably
`OsRng` has been renamed to `SysRng` (and is now provided by the
`getrandom` crate).
We do use some `rand_core` APIs in a few places though, like the STROBE
implementation, where this migrates from `rand_core::le` to
`rand_core::utils`.
When pulling crates via git (to grab non-released yet fixes or
otherwise), the `path = "../"` in each crate crates duplicates unless
you pull the whole tree in your local `[patch.crates-io]`.
This creates issues in downstream packaging (nix, ...) where a crate
version can only appear once.
Those are somewhat difficult to diagnose.
Using a `[patch.crates-io]` in the workspace serves the same purpose but
does not create the duplication in consumers' tree.
* Updated to new curve25519 scalar API
* Removed clamping from constructors; clamping is always done during scalar-point multiplication
* Updated test to reflect new functionality
* Updated changelog
* Add getrandom to bring convenience random init functions
* Fix doc name
* Rename new to random_from_rng
* Deprecate new() in favor of random_from_rng()
* Simplify constructors documentation
Co-authored-by: Ciprian Dorin Craciun <ciprian@volution.ro>
https://github.com/rust-random/rand/blob/master/rand_core/CHANGELOG.md
This new version makes using rand_core on wasm seamless (thanks to the update of getrandom to v0.2)
The crate compiles well with this PR, but since some rand_core traits are publicly exposed in this crate's API, this is strictly speaking a breaking change.
This allows unifying dependencies with other crates using the `3.x` series of
the curve library. It is a semver patch-level change, because the x25519-dalek
API does not expose any details of the underlying curve implementation.
