1.19.0 (older version)
From google/supply-chain copy of chromium. By Adrian Taylor.
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 bytemuck is 1.20.0.
1.19.0 (older version)
From google/supply-chain copy of chromium. By Adrian Taylor.
1.17.1 (older version)
From google/supply-chain copy of chromium. By Lukasz Anforowicz.
Unsafe review comments can be found in https://crrev.com/c/5813463
1.16.0 — diff review from 1.15.0 only (older version)
From zcash/rust-ecosystem copy of zcash/librustzcash. Audited without comment by Daira Emma Hopwood.
1.16.0 — diff review from 1.15.0 only (older version)
From google/supply-chain copy of chromium. Audited without comment by Dana Jansens.
1.14.0 (older version)
From kornelski/crev-proofs copy of git.savannah.gnu.org.
Packaged for Guix (crates-io)
1.14.0 (older version)
From kornelski/crev-proofs copy of salsa.debian.org.
Only in debcargo (unstable). Changelog:
1.13.1 (older version)
From google/supply-chain copy of chromium. Audited without comment by George Burgess IV.
1.13.1 (older version)
From google/supply-chain copy of google/rust-crate-audits. By Manish Goregaokar, Łukasz Anforowicz.
Reviewed in CL 561111794
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.
This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…
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
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
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
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 bytemuck is 1.20.0.
1.14.3 (older version) Thoroughness: Low Understanding: Medium
by weiznich on 2024-02-29
Update from 1.14.0 to 1.14.3
1.4.1 (older version) Thoroughness: Medium Understanding: Medium
Approved without comment by inflation on 2021-11-08
1.2.0 (older version) Thoroughness: Low Understanding: Low
Approved without comment by kornelski on 2020-06-15
1.2.0 (older version) Thoroughness: Medium Understanding: Medium
by HeroicKatora on 2020-02-08
The crate gained quite a bit of interface since last time. I'm not quite sure how I feel about this at the moment but understanding definitely suffered from it.
Of most concern is definitely TransparentWrapper
which relies on the
internal implementation detail that the layout of a pointer type itself does
not change for transparent wrappers. This premise seems a very unlikely to be
invalidated from changes but nevertheless departs with only relying on
stabilized and fully RFCed properties.
Other than that, no critical changes and a continued trend of being cautious.
Notably the implementation of Contiguous guards against bad implementations
despite being unsafe to implement, the offset_of
macro is completely
safe(!)—a welcome change for such macros—and there are MIRI tests in CI.
The test suite could be a lot bigger but some tests are obviously foiled by MIRI rejecting some sound and UB-free code that relies on alignment checks, to avoid those incidentally succeeding in unsound code.
1.1.0 (older version) Thoroughness: Medium Understanding: High
by HeroicKatora on 2020-01-10
The implementation is rather conservative on many fronts and requires very
strong, sometimes even unnecessary, preconditions for all operations. But
this makes reasoning easier since you work with a consistent set of
assumptions. This is in contrast to zerocopy
which has at three differing
sets.
The biggest leap of unsafety is the assumption that slices strides and arrays
agree with the size of their elements. This is not quite likely to change,
ever, but it should be noted nevertheless. The exact wording of Pod
also
allows us to smuggle a type through its requirements. It takes some care to
try and only allow types that might violate the assumption by requiring a
defined repr
but in its wording forgets that repr(packed)
can be applied
to repr(rust)
. Thus, the following type conforms to the wording but not the
spirit behind it.
\#[repr(packed)] struct BadSize(u16, u8)
The easiest fix would be to explicitly list the requirement that the size is divisible by the alignment. This defines the stride to agree with the size.
1.1.0 (older version) Thoroughness: High Understanding: High
by Lokathor on 2019-12-11
This is my crate. It's been in careful development for several months now, and it keeps everything as minimal and simple as possible to avoid any possible unsoundness.
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 bytemuck
. Alternatively, you can download the tarball of bytemuck v1.20.0 or view the source online.
No code changes - just comment changes and adding the track_caller attribute.