Lib.rs

› getrandom › Reviews

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 getrandom is 0.3.0-rc.0.

0.2.12 (older version) unknown

From kornelski/crev-proofs copy of salsa.debian.org.

Only in debcargo (unstable). Changelog:

  • Team upload.
  • Package getrandom 0.2.12 from crates.io using debcargo 2.6.1 (Closes: #1061675)
  • Reduce context in drop-js-wasm.patch to avoid fuzz.

0.2.10 — diff review from 0.2.9 only (older version) safe-to-deploy

From divviup/libprio-rs. By Tim Geoghegan.

These changes include some new unsafe code for the emscripten and psvita targets, but all it does is call libc::getentropy.

0.2.9 — diff review from 0.2.8 only (older version) safe-to-deploy

From zcash/rust-ecosystem copy of zcash/zcash. By str4d.

The new getrandom_uninit method is introduced by retrofitting every system implementation to take &mut [MaybeUninit<u8>] instead of &mut [u8].

Most implementations are only altered to update their signature, and to internally cast the slice back to *mut u8 when writing to it. All of these backends appear to write bytes to the full length of the slice, so it should be fully initialized afterwards, upholding the invariants of the new unsafe code in the public APIs.

  • I did not check the behaviour of each implementation's system method to ensure they never write uninitialized bytes; the code prior to this change already needed to uphold that invariant as it was writing into &mut [u8].

The following system implementations have additional unsafe code modifications:

  • custom: The slice is zero-filled to ensure the MaybeUninit<u8> doesn't escape into a system implementation that might not write initialized bytes into the entire slice. The internal API between registration and usage is also switched from C ABI to Rust ABI, to guard against potential panics.

  • emscripten: New backend, implementation looks reasonable.

  • hermit: New backend, writes incrementally to the slice, but ensures that the entire slice has been written to before returning Ok(()). I note that it is possible for the implementation to loop indefinitely if sys_read_entropy were to always return 0 for some reason.

  • js: Adds chunking to limit each write to less than 2^31 (but that seems like a bugfix). The safety requirements for Uint8Array::view_mut_raw appear to be satisfied.

  • rdrand: Code changes to better handle CPU families with broken RDRAND.

  • solaris_illumos: Now uses GRND_RANDOM.

  • windows: Added RtlGenRandom fallback for non-UWP Windows.

0.2.7 — diff review from 0.2.6 only (older version) safe-to-deploy

From zcash/rust-ecosystem copy of zcash/zcash. By Jack Grigg.

Checked that getrandom::wasi::getrandom_inner matches wasi::random_get. Checked that getrandom::util_libc::Weak lock ordering matches std::sys::unix::weak::DlsymWeak.

cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.

safe-to-deploy (implies safe-to-run)

This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…

safe-to-run

This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…

does-not-implement-crypto (implies crypto-safe)

Inspection reveals that the crate in question does not attempt to implement any cryptographic algorithms on its own.

Note that certification of this does not require an expert on all forms of cryptography: it's expected for crates we import to be "good enough" citizens, so they'll at least be forthcoming if they try to implement something cryptographic. When in doubt, please ask an expert.

crypto-safe
Implied by other criteria

All crypto algorithms in this crate have been reviewed by a relevant expert.

Note: If a crate does not implement crypto, use does-not-implement-crypto, which implies crypto-safe, but does not require expert review in order to audit for.

ub-risk-2 (implies ub-risk-3)

Negligible unsoundness or average soundness.

Full description of the audit criteria can be found at https://github.com/google/rust-crate-audits/blob/main/auditing_standards.md#ub-risk-2

ub-risk-3 (implies ub-risk-4)
Implied by other criteria

Mild unsoundness or suboptimal soundness.

Full description of the audit criteria can be found at https://github.com/google/rust-crate-audits/blob/main/auditing_standards.md#ub-risk-3

ub-risk-4
Implied by other criteria

Extreme unsoundness.

Full description of the audit criteria can be found at https://github.com/google/rust-crate-audits/blob/main/auditing_standards.md#ub-risk-4

unknown

May have been packaged automatically without a review

These reviews are from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.

The current version of getrandom is 0.3.0-rc.0.

0.2.12 (older version) Rating: Positive Thoroughness: Low Understanding: Medium

by weiznich on 2024-02-29

Review update from 0.2.10 to 0.2.12

  • Removed copy right headers
  • Target specific adjustments
  • Removed a unsafe primitive implementation

0.1.12 (older version) Rating: Positive Thoroughness: Medium Understanding: High

by gitlab.com/KonradBorowski on 2019-10-01

When programming for HermitCore, L4Re, UEFI or SGX on x86_64, this crate will use rdrand as source of randomness, which may have a backdoor. This looks fine on other platforms, using built-in operating system CSPRNG generation functions, assuming the operating system vendors didn't screw up those functions - and if they did, you have a problem, whatever or not this crate is secure.

Lib.rs has been able to verify that all files in the crate's tarball, except Cargo.lock, 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 getrandom. Alternatively, you can download the tarball of getrandom v0.3.0-rc.0 or view the source online.