Not high-priority, but I'd love to clean up the dependency graph, which currently looks like this:
cargo outdated reports that our rand hierarchy is out of date, and looking at the graph shows stuff like rand_jitter and rand_isaac that I don't want.. all I want is a kernel getrandom() call. In the rand ecosystem, that comes from a type named OsRng.
In the modern/current rand ecosystem, OsRng can be obtained from rand_core (but only in the latest 0.5.1 release), or rand_os (which is deprecated in favor of rand_core). So my ideal situation is to depend on rand_core = 0.5.1 and not rand.
Alas, x25519-dalek requires an rng with the RngCore and CryptoRng traits from the rand_core = 0.3 release, which (I think) gets those traits from rand_core = 0.4, but which is not compatible with the traits from rand_core = 0.5.
The most modern (and most minimal) dependency I could use to satisfy this for an OsRng is from rand_os = 0.1, although then I have to suppress the deprecation warnings (rand_os = 0.2 can be replaced by rand_core = 0.5.1, hence it is deprecated, but I can't use rand_core = 0.5.anything because of the incompatibility). To do that, I use the following patch:
% git diff --cached -- Cargo.toml src/lib.rs
diff --git a/Cargo.toml b/Cargo.toml
index 0e8eb34..6d4770e 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -21,7 +21,7 @@ travis-ci = { repository = "warner/wireguard-vanity-address" }
[dependencies]
rayon = "1.0"
base64 = "0.10"
-rand = "0.6.0"
+rand_os = "0.1"
x25519-dalek = "0.5.1"
[dev-dependencies]
diff --git a/src/lib.rs b/src/lib.rs
index 428bf37..0124d7a 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -1,9 +1,12 @@
use base64;
-use rand::thread_rng;
+#[allow(deprecated)]
+use rand_os::OsRng;
use x25519_dalek::{PublicKey, StaticSecret};
pub fn trial(prefix: &str, within: usize) -> bool {
- let mut rng = thread_rng();
+ #[allow(deprecated)]
+ let mut rng = OsRng::new().unwrap();
+ #[allow(deprecated)]
let private = StaticSecret::new(&mut rng);
let public = PublicKey::from(&private);
let public_b64 = base64::encode(public.as_bytes());
and I wind up with the following graph:
which is indeed somewhat simpler, but still pulling things I'd like to avoid.
I expect that eventually the *25519-dalek ecosystem will move to the current rand traits, and then I can depend upon rand_core = 0.5 and it will all be simpler again, but that's a compatibility-breaking change for them, so I imagine they'll wait until they have some other functional changes that are worth the compatibility break.
172fb75fa2a5eab208ee0618d2b9a4ee5ccd19a4 fixes this: now that rand_core includes a basic OsRng, we no longer need the full hierarchy. The new graph looks like this:
Not high-priority, but I'd love to clean up the dependency graph, which currently looks like this:
cargo outdated
reports that ourrand
hierarchy is out of date, and looking at the graph shows stuff likerand_jitter
andrand_isaac
that I don't want.. all I want is a kernelgetrandom()
call. In therand
ecosystem, that comes from a type namedOsRng
.In the modern/current
rand
ecosystem,OsRng
can be obtained fromrand_core
(but only in the latest 0.5.1 release), orrand_os
(which is deprecated in favor ofrand_core
). So my ideal situation is to depend onrand_core = 0.5.1
and notrand
.Alas,
x25519-dalek
requires an rng with theRngCore
andCryptoRng
traits from therand_core = 0.3
release, which (I think) gets those traits fromrand_core = 0.4
, but which is not compatible with the traits fromrand_core = 0.5
.The most modern (and most minimal) dependency I could use to satisfy this for an
OsRng
is fromrand_os = 0.1
, although then I have to suppress the deprecation warnings (rand_os = 0.2
can be replaced byrand_core = 0.5.1
, hence it is deprecated, but I can't userand_core = 0.5.anything
because of the incompatibility). To do that, I use the following patch:and I wind up with the following graph:
which is indeed somewhat simpler, but still pulling things I'd like to avoid.
I expect that eventually the *25519-dalek ecosystem will move to the current
rand
traits, and then I can depend uponrand_core = 0.5
and it will all be simpler again, but that's a compatibility-breaking change for them, so I imagine they'll wait until they have some other functional changes that are worth the compatibility break.