0.6.0 (older version) Thoroughness: Medium Understanding: Medium
by MaulingMonkey on 2019-07-25
These reviews are from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.
The current version of RdRand is 0.8.3.
0.5.2 (older version) Thoroughness: Medium Understanding: Medium
by MaulingMonkey on 2019-07-25
Show review…
Sound, although buggy AMD hardware makes implementing CryptoRng for RdRand/RdSeed a little unnerving to me ( https://github.com/nagisa/rust_rdrand/issues/12 )
Reviewed: benches\rdrand.rs: +1 benches\rdseed.rs: +1 benches\std.rs: +1 src\changelog.rs: +1 src\lib.rs: 0 All of $gen::try_fill_bytes::imp being unsafe is still concerning... but I believe it's sound now. RdRand/RdSeed implement CrytoRng, which makes buggy AMD hardware concerning: https://github.com/nagisa/rust_rdrand/issues/12
Concerns reduced since 0.4.0: https://github.com/nagisa/rust_rdrand/commit/7af432c6e315fde053d0056d1b7df893a865711a unsafe blocks appear much larger than they need to be.
Concerns fixed since 0.4.0: https://github.com/nagisa/rust_rdrand/commit/26a0a2f9d885fbbb8e14fa47c8a48e366cf15455 mem::uninitialized() u32s loop_rand! uses mem::uninitialized() for $el:ty, easy to misuse! Requires unsafe{} so technically sound. Not exported. https://github.com/nagisa/rust_rdrand/commit/7af432c6e315fde053d0056d1b7df893a865711a $gen::try_fill_bytes: UNSOUND! word and buffer reference the same data. As both are &mut Ts, this is 100% undefined behavior. ptr::copy_nonoverlapping: This should really use a slice copy which should be just as safe...? But maybe missing from core? Verified vs https://www.amd.com/system/files/TechDocs/24594.pdf is_x86_feature_detected: I have not verified this is correct.
0.4.0 (older version) Thoroughness: Low Understanding: Low
Approved without comment by kornelski on 2019-07-22
These reviews are from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.
The current version of RdRand is 0.8.3.
0.6.0 (older version)
From kornelski/crev-proofs copy of salsa.debian.org.
Only in debcargo (unstable). Changelog:
- Package rdrand 0.6.0 from crates.io using debcargo 2.4.0
0.4.0 (older version)
From kornelski/crev-proofs copy of git.savannah.gnu.org.
Packaged for Guix (crates-io)
cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.
- unknown
-
May have been packaged automatically without a review
Lib.rs has been able to verify that all files in the crate's tarball are in the crate's repository with a git tag matching the version. Please note that this check is still in beta, and absence of this confirmation does not mean that the files don't match.
Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories, so there is a possibility that published crates have a misleading repository URL, or contain different code from the code in the repository.
To review the actual code of the crate, it's best to use cargo crev open rdrand. Alternatively, you can download the tarball of rdrand v0.8.3 or view the source online.
Sound, although buggy AMD hardware makes implementing CryptoRng for RdRand/RdSeed a little unnerving to me ( https://github.com/nagisa/rust_rdrand/issues/12 )
Reviewed: benches\rdrand.rs: +1 benches\rdseed.rs: +1 benches\std.rs: +1 src\changelog.rs: +1 src\lib.rs: 0 All of $gen::try_fill_bytes::imp being unsafe is still concerning... but I believe it's sound now. RdRand/RdSeed implement CrytoRng, which makes buggy AMD hardware concerning: https://github.com/nagisa/rust_rdrand/issues/12
Concerns reduced since 0.4.0: https://github.com/nagisa/rust_rdrand/commit/7af432c6e315fde053d0056d1b7df893a865711a unsafe blocks appear much larger than they need to be.
Concerns fixed since 0.4.0: https://github.com/nagisa/rust_rdrand/commit/26a0a2f9d885fbbb8e14fa47c8a48e366cf15455 mem::uninitialized() u32s loop_rand! uses mem::uninitialized() for $el:ty, easy to misuse! Requires unsafe{} so technically sound. Not exported. https://github.com/nagisa/rust_rdrand/commit/7af432c6e315fde053d0056d1b7df893a865711a $gen::try_fill_bytes: UNSOUND! word and buffer reference the same data. As both are &mut Ts, this is 100% undefined behavior. ptr::copy_nonoverlapping: This should really use a slice copy which should be just as safe...? But maybe missing from core? Verified vs https://www.amd.com/system/files/TechDocs/24594.pdf is_x86_feature_detected: I have not verified this is correct.