2.7.0 (older version)
From google/supply-chain copy of chromium. By Lukasz Anforowicz.
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 data-encoding is 2.8.0.
2.7.0 (older version)
From google/supply-chain copy of chromium. By Lukasz Anforowicz.
2.6.0 (older version)
From google/supply-chain copy of chromium. Audited without comment by George Burgess IV.
2.5.0 (older version)
From kornelski/crev-proofs copy of git.savannah.gnu.org.
Packaged for Guix (crates-io)
2.5.0 (older version)
From kornelski/crev-proofs copy of salsa.debian.org.
Only in debcargo (unstable). Changelog:
2.3.3 — diff review from 2.3.2 only (older version)
From mozilla/supply-chain copy of hg. Audited without comment by Mike Hommey.
cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.
This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…
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.
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.
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
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
This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…
May have been packaged automatically without a review
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 data-encoding
. Alternatively, you can download the tarball of data-encoding v2.8.0 or view the source online.
https://github.com/ia0/data-encoding/issues/75 was partially addressed via
#[doc(hidden)]
added in https://github.com/ia0/data-encoding/pull/76, but the original repro from issue #75 can still trigger Undefined Behavior through public APIs exposed by thedata-encoding
crate (without usingunsafe
, and without using APIs named something likeinternal_field_do_not_use
).Additionally, the discussion in https://github.com/ia0/data-encoding/issues/124 leans toward
unsafe
encapsulation at a crate level, requiring crate-global reasoning to prove soundness of public crate APIs. Specifically, the crate currently has a internal function that can cause Undefined Behavior if the caller doesn't uphold certain (implied, not explicitly documented) safety requirements. The fact that such function is not marked asunsafe
effectively means that safety audit can't terminate and use local reasoning nearunsafe
expression boundaries.