Cryptographically verifiable, distributed dependency reviews
reviewer: Minoru.git
$ cargo crev repo fetch url https://github.com/Minoru/crev-proofs.git$ cargo crev id trust kQ1fVKX-nZhluPcz1Wj7PGsAgUe7sEeNXPCi0qDJQCwrepo: https://github.com/Minoru/crev-proofs.git
Please, use mobile in landscape.
This is an implementation of Adler-32 checksum. It has no unsafe, and the
code is quite simple. The only complicated part is the algorithm itself, but
there is a big comment explaining what's going on, and the structure of the
code matches the explanation. I can't vouch the implementation is bug-free,
but I'm sure it's sound and isn't malicious.
Thoroughness is "high" because I read the whole crate quite attentively, but
understanding is still "medium" since I didn't quite follow the math that
enables vectorization in this crate.
No unsafe code. The rest looks benign: the crate emits little bits of code
and runs them through the compiler to detect features. The test suite is
minimal but looks complete.
No unsafe code. The rest looks benign: the crate emits little bits of code
and runs them through the compiler to detect features. The test suite is
minimal but looks complete.
There's only one meaningful change since 1.3.1: non-snake-case names are
allowed in generated structs. My previous review stands.
There's only one meaningful change since 1.3.1: non-snake-case names are
allowed in generated structs. My previous review stands.
bitflags is a set of macros. They all look clean and correct. I flipped
through the tests too, and although I didn't pay as much attention, they too
look good — there are certainly more of them than of macros themselves, so
I'm quite confident about them. The docs are good too.
bitflags is a set of macros. They all look clean and correct. I flipped
through the tests too, and although I didn't pay as much attention, they too
look good — there are certainly more of them than of macros themselves, so
I'm quite confident about them. The docs are good too.
I compared this to crypto/memneq.c from Linux 5.7-rc5; the algorithm is
indeed the same, and I understand how it works. There are comments for all
the unobvious bits, too. I am not formally trained in cryptography, but
I posses basic knowledge and I believe this code to be secure for any
application.
I compared this to crypto/memneq.c from Linux 5.7-rc5; the algorithm is
indeed the same, and I understand how it works. There are comments for all
the unobvious bits, too. I am not formally trained in cryptography, but
I posses basic knowledge and I believe this code to be secure for any
application.
Overwriting my earlier review: this crate is maintained, development moved to https://github.com/dirs-dev
Appears to be unmaintained:
- repository on GitHub is archived without any notices in the README: https://github.com/soc/dirs-rs
- crate is co-maintained by @tbu, but their fork wasn't updated since Dec 26, 2015: https://github.com/tbu-/dirs
Overwriting my earlier review: this crate is maintained, development moved to https://github.com/dirs-dev
Appears to be unmaintained:
- repository on GitHub is archived without any notices in the README: https://github.com/soc/dirs-rs
- crate is co-maintained by @tbu, but their fork wasn't updated since Dec 26, 2015: https://github.com/tbu-/dirs
Overwriting my earlier review: this crate is maintained, development moved to https://github.com/dirs-dev
Appears to be unmaintained:
- GitHub repo is archived without any notices in the README: https://github.com/soc/dirs-sys-rs
- no co-maintainers on crates.io
Overwriting my earlier review: this crate is maintained, development moved to https://github.com/dirs-dev
Appears to be unmaintained:
- GitHub repo is archived without any notices in the README: https://github.com/soc/dirs-sys-rs
- no co-maintainers on crates.io
I evaluated this before using in my own project. I only really know Linux,
but WASI and Windows parts made sense to me as well. I can't vouch for
memory safety of WinAPI calls, so I capped the rating at "positive" rather
than giving it the "strong" that it probably deserves.
I evaluated this before using in my own project. I only really know Linux,
but WASI and Windows parts made sense to me as well. I can't vouch for
memory safety of WinAPI calls, so I capped the rating at "positive" rather
than giving it the "strong" that it probably deserves.
This new version adds trivial methods to get the seed out of an existing
generator. I don't see any problem with this feature.
My recommendation stands: use this as a non-cryptographic PRNG if you don't
already depend on rand and want to keep your dependencies to the minimum.
This new version adds trivial methods to get the seed out of an existing
generator. I don't see any problem with this feature.
My recommendation stands: use this as a non-cryptographic PRNG if you don't
already depend on rand and want to keep your dependencies to the minimum.
Compared to 1.6.0, the Cargo.toml indicates MSRV of 1.34, and there is a newchar() method to generate characters. The code looks clean enough, contains
to unsafe, and I don't see any flaws in it.
My recommendation stands: use this as a non-cryptographic PRNG if you don't
already depend on rand and want to keep your deps to the minimum.
Compared to 1.6.0, the Cargo.toml indicates MSRV of 1.34, and there is a newchar() method to generate characters. The code looks clean enough, contains
to unsafe, and I don't see any flaws in it.
My recommendation stands: use this as a non-cryptographic PRNG if you don't
already depend on rand and want to keep your deps to the minimum.
Compared to 1.5.0, this release only adds #[derive(PartialEq, Eq)] for theRng type. It's now possible to check if the generator is in a particular
state, but this was already possible through the Debug trait. Considering
the crate is not for cryptographic use, this seems totally fine to me.
My recommendation stands: use this as a non-cryptographic PRNG if you don't
already depend on rand and want to keep your deps to the minimum.
Compared to 1.5.0, this release only adds #[derive(PartialEq, Eq)] for theRng type. It's now possible to check if the generator is in a particular
state, but this was already possible through the Debug trait. Considering
the crate is not for cryptographic use, this seems totally fine to me.
My recommendation stands: use this as a non-cryptographic PRNG if you don't
already depend on rand and want to keep your deps to the minimum.
Generates random numbers using Wyrand algorithm (which is not
cryptographically secure, but ostensibly passes some popular tests — I didn't
verify that).
No unsafe, no dependencies other than std (except on WASM, where it pulls
in instant crate to get initial entropy).
By default, the generator is initialized from a hash of
std::time::Instant::now() and process ID. Good enough for a non-cryptographic
PRNG.
Interesting detail: if the thread-local storage has already been
de-initialized by we try to use it, the generator is initialized by a fixed
seed 0x4d595df4d0f33173. This constant is an initial state for PCG-XSH-RR,
which is an algorithm that previous versions of the crate used.
I verified that the algorithms match the documents they reference:
wyrand() inI also verified that the algorithms that generate floating-point numbers
indeed do what they're supposed to do: set sign to 0 (i.e. positive),
exponent to 127 (i.e. zero), then fill the fraction with random bits, and
subtracting 1.0 from the result to get [0; 1).
Also worth mentioning that the crate doesn't guarantee a specific algorithm,
so you shouldn't depend on a specific seed to always produce the same
results.
Recommended for non-cryptographic purposes that do not require
reproducibility.
Generates random numbers using Wyrand algorithm (which is not
cryptographically secure, but ostensibly passes some popular tests — I didn't
verify that).
No unsafe, no dependencies other than std (except on WASM, where it pulls
in instant crate to get initial entropy).
By default, the generator is initialized from a hash of
std::time::Instant::now() and process ID. Good enough for a non-cryptographic
PRNG.
Interesting detail: if the thread-local storage has already been
de-initialized by we try to use it, the generator is initialized by a fixed
seed 0x4d595df4d0f33173. This constant is an initial state for PCG-XSH-RR,
which is an algorithm that previous versions of the crate used.
I verified that the algorithms match the documents they reference:
wyrand() inI also verified that the algorithms that generate floating-point numbers
indeed do what they're supposed to do: set sign to 0 (i.e. positive),
exponent to 127 (i.e. zero), then fill the fraction with random bits, and
subtracting 1.0 from the result to get [0; 1).
Also worth mentioning that the crate doesn't guarantee a specific algorithm,
so you shouldn't depend on a specific seed to always produce the same
results.
Recommended for non-cryptographic purposes that do not require
reproducibility.
FNV is an extremely simple hashing algorithm. This crate implements a variant
called FNV-1a.
It uses no unsafe, and just basic arithmetic. Half the code is actually
tests. I'm convinced that there are no bugs here, and definitely no malicious
code.
FNV is an extremely simple hashing algorithm. This crate implements a variant
called FNV-1a.
It uses no unsafe, and just basic arithmetic. Half the code is actually
tests. I'm convinced that there are no bugs here, and definitely no malicious
code.
The crate encodes and decodes parameters of web forms.
I verified that the decoding algorithm matches the spec. The encoding is more
involved, so I didn't verify that. Notably, the crate has no tests, so I only
trust to it be correct because it's written by the Servo team.
There are two uses of unsafe, for performance (avoiding UTF-8 checks). Both
have comments explaining why they're okay, and they sound convincing enough.
The crate encodes and decodes parameters of web forms.
I verified that the decoding algorithm matches the spec. The encoding is more
involved, so I didn't verify that. Notably, the crate has no tests, so I only
trust to it be correct because it's written by the Servo team.
There are two uses of unsafe, for performance (avoiding UTF-8 checks). Both
have comments explaining why they're okay, and they sound convincing enough.
This is a self-review, because this release is made by me and contains only
the changes that I made.
The crate provides safe wrappers over an FFI for GNU gettext (which is
packaged separately, as a gettext-sys crate). There are no known issues with
those wrappers.
This release fixes an incorrect default for XDG_DATA_DIRS. There are no
security implications to this change, as far as I can see.
This is a self-review, because this release is made by me and contains only
the changes that I made.
The crate provides safe wrappers over an FFI for GNU gettext (which is
packaged separately, as a gettext-sys crate). There are no known issues with
those wrappers.
This release fixes an incorrect default for XDG_DATA_DIRS. There are no
security implications to this change, as far as I can see.
This is basically a self-review, since it's me who fixed the problems
I highlighted in my previous review.
This crate contains safe FFI bindings for gettext.
The memory issues I mentioned in the previous review are fixed, and panics
documented. There are no unwraps, and all errors are propagated viaResults.
The crate still depends on gettext returning UTF-8, but this is now
prominently documented.
Compared to 0.5.0, the API is more fleshed out and polished (even if I say so
myself).
This is basically a self-review, since it's me who fixed the problems
I highlighted in my previous review.
This crate contains safe FFI bindings for gettext.
The memory issues I mentioned in the previous review are fixed, and panics
documented. There are no unwraps, and all errors are propagated viaResults.
The crate still depends on gettext returning UTF-8, but this is now
prominently documented.
Compared to 0.5.0, the API is more fleshed out and polished (even if I say so
myself).
The crate provides safe wrappers for FFI bindings from gettext-sys crate.
The bindings are suspicious as they might use already-deallocated memory[1],
and they don't document panic conditions[2].
Furthermore, the library seems to assume that the locale charset is UTF-8[3],
which if false can lead to garbled translations as non-UTF-8 bytes would be
replaced by U+FFFD.
The UTF-8 and documentation issues would cap the rating at "positive", but
the memory issue puts this crate into "negative" territory.
The crate provides safe wrappers for FFI bindings from gettext-sys crate.
The bindings are suspicious as they might use already-deallocated memory[1],
and they don't document panic conditions[2].
Furthermore, the library seems to assume that the locale charset is UTF-8[3],
which if false can lead to garbled translations as non-UTF-8 bytes would be
replaced by U+FFFD.
The UTF-8 and documentation issues would cap the rating at "positive", but
the memory issue puts this crate into "negative" territory.
This is basically a self-review, since it's me who fixed the problems
I highlighted in my previous review.
The crate now bundles an up-to-date version of GNU gettext, which is nice.
The documentation now features a prominent warning about the bundled
library's license, LGPL.
This release added one new binding and some workarounds for build issues. All
of that looks good to me (but remember that I'm the author of those changes).
The crate is now even more solid than before.
This is basically a self-review, since it's me who fixed the problems
I highlighted in my previous review.
The crate now bundles an up-to-date version of GNU gettext, which is nice.
The documentation now features a prominent warning about the bundled
library's license, LGPL.
This release added one new binding and some workarounds for build issues. All
of that looks good to me (but remember that I'm the author of those changes).
The crate is now even more solid than before.
This crate bundles an older version of GNU gettext and provides unsafe
FFI bindings.
I checked, and bindings indeed correspond to the contents of the C headers
libintl.h and locale.h.
The only complex part of this crate is a build script, but it mostly deals
with platform differences. There are a few FIXMEs, but they're all benign.
The bundled library is licensed under LGPL, which puts some restrictions on
how it can be used. The crate's documentation currently doesn't make this
clear though: https://github.com/Koka/gettext-rs/issues/31
Giving a strong rating because code-wise, this is a solid crate, and
licensing issues don't change that.
This crate bundles an older version of GNU gettext and provides unsafe
FFI bindings.
I checked, and bindings indeed correspond to the contents of the C headers
libintl.h and locale.h.
The only complex part of this crate is a build script, but it mostly deals
with platform differences. There are a few FIXMEs, but they're all benign.
The bundled library is licensed under LGPL, which puts some restrictions on
how it can be used. The crate's documentation currently doesn't make this
clear though: https://github.com/Koka/gettext-rs/issues/31
Giving a strong rating because code-wise, this is a solid crate, and
licensing issues don't change that.
The diff from 0.1.0 doesn't contain anything suspicious. Still no unsafe.
The issues I mentioned in my previous review were all addressed.
I now consider this library mature enough to be used in production (in my
case, Newsboat).
The diff from 0.1.0 doesn't contain anything suspicious. Still no unsafe.
The issues I mentioned in my previous review were all addressed.
I now consider this library mature enough to be used in production (in my
case, Newsboat).
No unsafe, no dependencies except std. About 1KLOC.
Tries hard not to convert OsStrings into String unless absolutely
necessary. I didn't review the Windows/UTF-16 bits, but everything else looks
tidy enough.
This is just the first release, so some bits are inconsistent. I reported them:
They aren't flaws, but they do indicate that the library is not yet mature
(to no-one's surprise).
No unsafe, no dependencies except std. About 1KLOC.
Tries hard not to convert OsStrings into String unless absolutely
necessary. I didn't review the Windows/UTF-16 bits, but everything else looks
tidy enough.
This is just the first release, so some bits are inconsistent. I reported them:
They aren't flaws, but they do indicate that the library is not yet mature
(to no-one's surprise).
Compared to 0.2.138, the bulk of the changes are support for new target_os,nto, which is QNX/Neutrino. I glanced through them, they seem to have the
right shape. The rest of the changes are the usual: new constants and new
function declarations. The only interesting bit there is a newKERNEL_VERSION function which emulates the eponymous macro; it returns the
kernel version, limiting the patch version to 255 (for compatibility).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.138, the bulk of the changes are support for new target_os,nto, which is QNX/Neutrino. I glanced through them, they seem to have the
right shape. The rest of the changes are the usual: new constants and new
function declarations. The only interesting bit there is a newKERNEL_VERSION function which emulates the eponymous macro; it returns the
kernel version, limiting the patch version to 255 (for compatibility).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.137, this version adds some new constants and bindings. The
only interesting bit is two new wrappers in unix::solarish::compat module
that wrap getpwent_r and getgrent_r functions in such a way that calls
don't modify errno. The wrappers look solid to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.137, this version adds some new constants and bindings. The
only interesting bit is two new wrappers in unix::solarish::compat module
that wrap getpwent_r and getgrent_r functions in such a way that calls
don't modify errno. The wrappers look solid to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version un-deprecates recvmmsg() flags deprecated
by the previous version. It also adds a few constants for madvise(), and
function declarations for dirname() and basename().
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version un-deprecates recvmmsg() flags deprecated
by the previous version. It also adds a few constants for madvise(), and
function declarations for dirname() and basename().
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version adds more constants, more structs, and more
function declarations. It also deprecates some of recvmmsg() flags, and adds
Apple tvOS as a target to some of Apple calls.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.135, this version adds more constants, more structs, and more
function declarations. It also deprecates some of recvmmsg() flags, and adds
Apple tvOS as a target to some of Apple calls.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.134, this version adds more consts and function prototypes --
nothing suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.134, this version adds more consts and function prototypes --
nothing suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.133, this tiny update only adds a couple new function
prototypes and a few new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.133, this tiny update only adds a couple new function
prototypes and a few new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.132, this version adds some new types, structs, consts, and
function prototypes. It also deprecates some constants on FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.132, this version adds some new types, structs, consts, and
function prototypes. It also deprecates some constants on FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.131, this version fixes one constant, adds another, and
provides one new function signature. That's it.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.131, this version fixes one constant, adds another, and
provides one new function signature. That's it.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm again rolling two releases into a single review because 0.2.130 was
yanked from crates.io for unknown reason.
Compared to 0.2.129, this version only adds a couple functions for GNU/Linux,
and fixes a type of a constant for Unix newlib. Nothing major at all.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm again rolling two releases into a single review because 0.2.130 was
yanked from crates.io for unknown reason.
Compared to 0.2.129, this version only adds a couple functions for GNU/Linux,
and fixes a type of a constant for Unix newlib. Nothing major at all.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm rolling two crate releases into a single review because 0.2.128 was
yanked: https://github.com/rust-lang/libc/issues/2866
Compared to 0.2.127, this release just adds some new sructs, consts, and fn
prototypes. It also shuffles around the code responsible for linking on
Android, and adds a workaround for *pintf functions on Windows when linking
with MSVC. All looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
I'm rolling two crate releases into a single review because 0.2.128 was
yanked: https://github.com/rust-lang/libc/issues/2866
Compared to 0.2.127, this release just adds some new sructs, consts, and fn
prototypes. It also shuffles around the code responsible for linking on
Android, and adds a workaround for *pintf functions on Windows when linking
with MSVC. All looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.126, this release is just bookkeeping. A bunch of new
constants and functions were added, some fixes were applied to existing ones,
and some code was reformatted.
The problem with struct field missing from the Hash impl that I mentioned
in my previous review has been fixed, too.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.126, this release is just bookkeeping. A bunch of new
constants and functions were added, some fixes were applied to existing ones,
and some code was reformatted.
The problem with struct field missing from the Hash impl that I mentioned
in my previous review has been fixed, too.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.125, this is just usual churn. I found a place where a struct
field is used in PartialEq but not Hash; I asked the author to check if
that's correct: https://github.com/rust-lang/libc/pull/2748/files#r880853330
Other than that, this looks solid.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.125, this is just usual churn. I found a place where a struct
field is used in PartialEq but not Hash; I asked the author to check if
that's correct: https://github.com/rust-lang/libc/pull/2748/files#r880853330
Other than that, this looks solid.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.124, this release adds more constants, structs, and function
prototypes, plus some support for LoongArch (MIPS-like CPUs from a Chinese
company Loongson).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.124, this release adds more constants, structs, and function
prototypes, plus some support for LoongArch (MIPS-like CPUs from a Chinese
company Loongson).
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.123, this release adds more constants, structs, and function
prototypes. The only interesting bit is si_addr and si_value methods forsiginfo_t on uclibc Linux: they use type punning to interpret siginfo_t
payload differently. They look fine to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.123, this release adds more constants, structs, and function
prototypes. The only interesting bit is si_addr and si_value methods forsiginfo_t on uclibc Linux: they use type punning to interpret siginfo_t
payload differently. They look fine to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.122, this release only adds a couple constants and function
signatures.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.122, this release only adds a couple constants and function
signatures.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The major change in this release is partial support for __int128 (and similar
types) for aarch64 platforms. As usual with libc, the actual code is
dead-simple; the actual work--verifying that rustc's representation matches
platform's--was done elsewhere. Looks okay to me.
And then there's the usual churn of function declarations and new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The major change in this release is partial support for __int128 (and similar
types) for aarch64 platforms. As usual with libc, the actual code is
dead-simple; the actual work--verifying that rustc's representation matches
platform's--was done elsewhere. Looks okay to me.
And then there's the usual churn of function declarations and new constants.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.119, this mostly contains the usual churn: more function
prototypes, some changes to attributes, typo fixes. The only interesting bit
is updates to siginfo_t on Solarish, where Unix signal payload is now
handled more intelligently. It's admittedly unfinished, but looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.119, this mostly contains the usual churn: more function
prototypes, some changes to attributes, typo fixes. The only interesting bit
is updates to siginfo_t on Solarish, where Unix signal payload is now
handled more intelligently. It's admittedly unfinished, but looks okay to me.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.118, this version only adds a few lgrp_* functions for
Solaris-like systems, and a constant on Apple AArch64.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.118, this version only adds a few lgrp_* functions for
Solaris-like systems, and a constant on Apple AArch64.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Most of the additions compared to 0.2.117 are related to System V contexts
support. There are also a bunch of new constants, a few new functions, and
a couple typo fixes. Nothing stands out to me in this release.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Most of the additions compared to 0.2.117 are related to System V contexts
support. There are also a bunch of new constants, a few new functions, and
a couple typo fixes. Nothing stands out to me in this release.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.116, this version removes the "How to apply the Apache
license to your work" appendix from the LICENSE file, and adds a bunch of
constants for Android and musl. Nothing hairy.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.116, this version removes the "How to apply the Apache
license to your work" appendix from the LICENSE file, and adds a bunch of
constants for Android and musl. Nothing hairy.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.115, this version is mostly about ARMv6K Nintendo 3DS
support, but it also adds a number of new constants and a couple functions.
Nothing scary.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.115, this version is mostly about ARMv6K Nintendo 3DS
support, but it also adds a number of new constants and a couple functions.
Nothing scary.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.114, this version adds one new constant, a couple new types,
and a few new structs. Looks legit.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.114, this version adds one new constant, a couple new types,
and a few new structs. Looks legit.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.113 only shows the usual churn: some constants got moved,
some functions got added, and one macro got fixed.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.113 only shows the usual churn: some constants got moved,
some functions got added, and one macro got fixed.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious, just the usual churn.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious, just the usual churn.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.111 reveals nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.110 is minuscule: just some BSD functions moved around, and
a new linker dependency added for FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.110 is minuscule: just some BSD functions moved around, and
a new linker dependency added for FreeBSD.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.109 contains all the usual stuff: some new FreeBSD work,
some deprecation removals, plus a bit of new misc stuff. Nothing malicious
as far as I can tell.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.109 contains all the usual stuff: some new FreeBSD work,
some deprecation removals, plus a bit of new misc stuff. Nothing malicious
as far as I can tell.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.108 shows nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.108 shows nothing malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 is large but boring. I didn't find anything malicious.
I did find a couple insignificant errors:
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 is large but boring. I didn't find anything malicious.
I did find a couple insignificant errors:
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 doesn't contain anything unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.107 doesn't contain anything unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.106 reveals nothing unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.106 reveals nothing unusual or malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.104 only contains the usual churn, nothing malicious. Some
new entries have doc comments, that's unusual for this crate :)
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.104 only contains the usual churn, nothing malicious. Some
new entries have doc comments, that's unusual for this crate :)
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Half of the diff since 0.2.103 is bindings for the new rustc target, SOLID.
The other half is the usual: more constants, some more bindings.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Half of the diff since 0.2.103 is bindings for the new rustc target, SOLID.
The other half is the usual: more constants, some more bindings.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.102 doesn't reveal anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.102 doesn't reveal anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.101 doesn't show anything malicious.
Funny typo: "errnoeously". Not worth reporting and fixing upstream, I think.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.101 doesn't show anything malicious.
Funny typo: "errnoeously". Not worth reporting and fixing upstream, I think.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.100 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.100 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.99 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.99 doesn't show anything malicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.98 doesn't reveal anything malicious. I found a couple
typos though, and submitted a PR to fix them:
https://github.com/rust-lang/libc/pull/2330
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.98 doesn't reveal anything malicious. I found a couple
typos though, and submitted a PR to fix them:
https://github.com/rust-lang/libc/pull/2330
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.97 doesn't reveal anything suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
The diff from 0.2.97 doesn't reveal anything suspicious.
As usual, "thoroughness" for this review is "low" because I didn't manually
check that the bindings match the headers — I trust that the CI checked that
already.
Compared to 0.2.95, there are two new functions (mallinfo2 and mstats) along
with their respective structs, and one new constant (AF_VSOCK).
Nothing fancy. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
Compared to 0.2.95, there are two new functions (mallinfo2 and mstats) along
with their respective structs, and one new constant (AF_VSOCK).
Nothing fancy. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
Delta from 0.2.95 doesn't show anything malicious, just the usual stuff: more
bindings, more constants, more types.
This looks fine. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
Delta from 0.2.95 doesn't show anything malicious, just the usual stuff: more
bindings, more constants, more types.
This looks fine. As usual, "thoroughness" for this review is "low" because
I didn't manually check that the bindings match the headers — I trust that
the CI checked that already.
Delta from 0.2.94 reveals nothing unusual: add new bindings, add new
constants, move some code around, and undo a macOS-related hack that
I committed earlier. Some FIXMEs were added too, but their comments don't
sound urgent.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
Delta from 0.2.94 reveals nothing unusual: add new bindings, add new
constants, move some code around, and undo a macOS-related hack that
I committed earlier. Some FIXMEs were added too, but their comments don't
sound urgent.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
Delta from 0.2.93 moves some TCP-related constants around, adds
RLIMIT_NLIMITS constant, and provides a few new function bindings.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
Delta from 0.2.93 moves some TCP-related constants around, adds
RLIMIT_NLIMITS constant, and provides a few new function bindings.
This looks fine. "Thoroughness" for this review is "low" because I didn't
manually check that the bindings match the headers — I trust that the CI
checked that already.
Delta from 0.2.92 consists mostly of two things: formatting changes, and
modularisation of some architecture-specific constants for Linux.
Packing was disabled for arphdr and in_addr on NetBSD. The commit message
sounds convincing to me
(https://github.com/rust-lang/libc/commit/ec13c82bc93070dfe1d81a359174e0495edfe487).
There's also a hint at a new CI machinery that'll ensure the crate doesn't
break semver.
Overall this looks fine to me. As usual, I rely on the project's CI to check
that the bindings match C, hence "thoroughness" is low.
Delta from 0.2.92 consists mostly of two things: formatting changes, and
modularisation of some architecture-specific constants for Linux.
Packing was disabled for arphdr and in_addr on NetBSD. The commit message
sounds convincing to me
(https://github.com/rust-lang/libc/commit/ec13c82bc93070dfe1d81a359174e0495edfe487).
There's also a hint at a new CI machinery that'll ensure the crate doesn't
break semver.
Overall this looks fine to me. As usual, I rely on the project's CI to check
that the bindings match C, hence "thoroughness" is low.
Delta from 0.2.91 mostly moves code around by adding const annotations. It
also introduces one new bindings (pwrite64). Nothing suspicious. As usual,
I rely on the project's CI to check that the bindings match C, hence
"thoroughness" is low.
Delta from 0.2.91 mostly moves code around by adding const annotations. It
also introduces one new bindings (pwrite64). Nothing suspicious. As usual,
I rely on the project's CI to check that the bindings match C, hence
"thoroughness" is low.
Delta from 0.2.90 only adds a single constant to a couple modules and edits
some docs. Looks okay to me. (As usual, I rely on the project's CI to check
if the constant is correct, hence "thoroughness" is low).
Delta from 0.2.90 only adds a single constant to a couple modules and edits
some docs. Looks okay to me. (As usual, I rely on the project's CI to check
if the constant is correct, hence "thoroughness" is low).
I checked that the delta from 0.2.89 doesn't add any suspicious code. It
indeed doesn't. I trust that ctest in the project's CI checked that all new
constants have the expected values, and that function signatures match C.
I checked that the delta from 0.2.89 doesn't add any suspicious code. It
indeed doesn't. I trust that ctest in the project's CI checked that all new
constants have the expected values, and that function signatures match C.
This crate contains unsafe bindings to platform-specific C functions. The
project has an expansive CI pipeline that runs ctest on Linux, macOS,
FreeBSD, and Windows. Where possible, the testing is done on multiple
architectures with different libc implementations.
Most of the crate is marked unsafe, but that's just the nature of the beast.
I only looked at one module, unix, so thoroughness is capped at "low".
However, the crate comes from the same people who build Rust itself, so this
doesn't affect the rating.
Given it's just a list of declarations, which are then automatically checked,
I'm fairly confident that this code does what it's supposed to do.
This crate contains unsafe bindings to platform-specific C functions. The
project has an expansive CI pipeline that runs ctest on Linux, macOS,
FreeBSD, and Windows. Where possible, the testing is done on multiple
architectures with different libc implementations.
Most of the crate is marked unsafe, but that's just the nature of the beast.
I only looked at one module, unix, so thoroughness is capped at "low".
However, the crate comes from the same people who build Rust itself, so this
doesn't affect the rating.
Given it's just a list of declarations, which are then automatically checked,
I'm fairly confident that this code does what it's supposed to do.
This update removes an implicit dependency on std and declares MSRV of 1.34.
No changes to the actual code, so my review for 1.0.4 stands.
This update removes an implicit dependency on std and declares MSRV of 1.34.
No changes to the actual code, so my review for 1.0.4 stands.
The delta since 1.0.4 only shows documentation changes. They also added
Clippy to the CI, which is nice.
No changes to the code, so my 1.0.4 review stands.
The delta since 1.0.4 only shows documentation changes. They also added
Clippy to the CI, which is nice.
No changes to the code, so my 1.0.4 review stands.
Another tiny-yet-useful crate. Lets the users request which C++ stdlib they'd
like to link to. If nobody cares, or if there are conflicting choices, it
punts the choice to the "cc" crate which picks the platform default.
I don't see anything suspicious here, and don't see a way to trick this crate
into doing something bad, thus a strong rating.
Another tiny-yet-useful crate. Lets the users request which C++ stdlib they'd
like to link to. If nobody cares, or if there are conflicting choices, it
punts the choice to the "cc" crate which picks the platform default.
I don't see anything suspicious here, and don't see a way to trick this crate
into doing something bad, thus a strong rating.
This is a tiny wrapper over a raw pointer allocated by malloc; this crate
provides a slice-like interface and ensures that the pointer is free()d when
the wrapper is dropped.
This looks solid to me.
This is a tiny wrapper over a raw pointer allocated by malloc; this crate
provides a slice-like interface and ensures that the pointer is free()d when
the wrapper is dropped.
This looks solid to me.
I don't grok the algorithm, but there is no unsafe, no dependencies, and no
super-weird code, so this looks fine to me.
I don't grok the algorithm, but there is no unsafe, no dependencies, and no
super-weird code, so this looks fine to me.
Contains no unsafe and no dependencies other than std, which is good. The
code is farly small, about 1KLOC.
Surprisingly complicated for such a small codebase: there are a couple helper
functions which are used throughout, and affect the state. I gave up trying
to model everything in my head, but what I did understand all looked okay.
Contains no unsafe and no dependencies other than std, which is good. The
code is farly small, about 1KLOC.
Surprisingly complicated for such a small codebase: there are a couple helper
functions which are used throughout, and affect the state. I gave up trying
to model everything in my head, but what I did understand all looked okay.
Version 0.3.1 adjusts links in Cargo.toml and disables a few Clippy lints.
There are no material changes to the crate, so my previous review stands.
Version 0.3.1 adjusts links in Cargo.toml and disables a few Clippy lints.
There are no material changes to the crate, so my previous review stands.
This is an implementation of an HC-128 RNG.
The crate has no unsafe, and doesn't seem to do anything obviously fishy.
I didn't compare the algorithm to the relevant paper though, so I don't vouch
this is a faithful implementation.
This is an implementation of an HC-128 RNG.
The crate has no unsafe, and doesn't seem to do anything obviously fishy.
I didn't compare the algorithm to the relevant paper though, so I don't vouch
this is a faithful implementation.
This implements a xorshift RNG with 128 bits of state.
The implementation uses no unsafe, and does not even require std. The code is
straightforward, and matches the code from the paper that describes the RNG
("Xorshift RNGs" by George Marsaglia).
Seeding from an existing RNG can theoretically hang if the seeding RNG keeps
returning zeroes. I filed https://github.com/rust-random/rngs/issues/24 about
this and capped the rating at "positive".
This implements a xorshift RNG with 128 bits of state.
The implementation uses no unsafe, and does not even require std. The code is
straightforward, and matches the code from the paper that describes the RNG
("Xorshift RNGs" by George Marsaglia).
Seeding from an existing RNG can theoretically hang if the seeding RNG keeps
returning zeroes. I filed https://github.com/rust-random/rngs/issues/24 about
this and capped the rating at "positive".
I'm not a Windows programmer; I merely took a peek to see if the crate is
blatantly malicious, and it looks like it isn't.
The code is well-commented. Uses unsafe sparingly, just to call WinAPI — no
high-performance tricks. Some comments refer to alignment issues, which shows
the amount of thought that went into the code; nice.
I'm not a Windows programmer; I merely took a peek to see if the crate is
blatantly malicious, and it looks like it isn't.
The code is well-commented. Uses unsafe sparingly, just to call WinAPI — no
high-performance tricks. Some comments refer to alignment issues, which shows
the amount of thought that went into the code; nice.
There were no material changes since 1.0.0, the main code wasn't even touched.
There were no material changes since 1.0.0, the main code wasn't even touched.
Trivial (but useful!) crate that creates a temporary directory which can be
seen by any crate that depends on this one.
There are just 6 lines of actual code here. They read OUT_DIR from
environment, and create/remove some directories.
A rogue crate could include this one and use it to stomp on some other
crate's scratch space. It's hard for me to see this as a vulnerability, since
the user is supposed to trust the code they're running during the build.
Trivial (but useful!) crate that creates a temporary directory which can be
seen by any crate that depends on this one.
There are just 6 lines of actual code here. They read OUT_DIR from
environment, and create/remove some directories.
A rogue crate could include this one and use it to stomp on some other
crate's scratch space. It's hard for me to see this as a vulnerability, since
the user is supposed to trust the code they're running during the build.
This crate implements "section testing" similar to Catch2 framework for C++.
The code is pure Rust, there is no dependencies, and there are no "unsafe".
As such, there are no worries about unsoundness.
However, the algorithm here is pretty involved, and after spending 20 minutes
staring at it, I still can't claim I grok how this code actually achieves
what it achieves. However, I am confident that this code is not malicious,
thus a positive rating.
This crate implements "section testing" similar to Catch2 framework for C++.
The code is pure Rust, there is no dependencies, and there are no "unsafe".
As such, there are no worries about unsoundness.
However, the algorithm here is pretty involved, and after spending 20 minutes
staring at it, I still can't claim I grok how this code actually achieves
what it achieves. However, I am confident that this code is not malicious,
thus a positive rating.
Delta since 1.0.0 only shows rustdoc improvements: module documentation is
hoisted into the root of the crate.
My review of 1.0.0 stands.
Delta since 1.0.0 only shows rustdoc improvements: module documentation is
hoisted into the root of the crate.
My review of 1.0.0 stands.
This crate provides three pieces of plumbing that makes it easier to chain
functions:
map();into() but lets you specify the target type, soA lot of pretty boring code. It looks all right to me, but I got too lazy to
check why functions usually require sized types; that's why I cap my
"thoroughness" and "understanding" at "medium", and rating at "positive".
This crate provides three pieces of plumbing that makes it easier to chain
functions:
map();into() but lets you specify the target type, soA lot of pretty boring code. It looks all right to me, but I got too lazy to
check why functions usually require sized types; that's why I cap my
"thoroughness" and "understanding" at "medium", and rating at "positive".
Short and to the point.
Could contain fewer unwraps:
Windows support could be better:
Looks like a reliable crate overall.
Short and to the point.
Could contain fewer unwraps:
Windows support could be better:
Looks like a reliable crate overall.
A high-quality create with no unsafe, no unwraps or expects. Has thorough documentation and good tests.
A high-quality create with no unsafe, no unwraps or expects. Has thorough documentation and good tests.
Runs rustc --verbose --version and parses the result. The binary to run can
be overridden via an environment variable RUSTC, which I do not consider as
a security risk since it's done at build time.
There is no unsafe, and the code itself is mostly string mangling, so
I think this crate is okay.
Runs rustc --verbose --version and parses the result. The binary to run can
be overridden via an environment variable RUSTC, which I do not consider as
a security risk since it's done at build time.
There is no unsafe, and the code itself is mostly string mangling, so
I think this crate is okay.
The crate implements a seemingly trivial thing: waiting for a child process
to finish, with a timeout.
On Windows, this boils down to a single WinAPI call. I don't know much about
Windows, but the code looks okay to me. There is a minor issue of timeouts
being capped at ≈49 days, which I reported:
https://github.com/alexcrichton/wait-timeout/issues/23
On Unix, the algorithm is much more involved. I understand it, and I believe
it to be correct.
The crate calls into libc and WinAPI, so there are a bit of unsafe in here.
But it all looks all right to me.
The crate implements a seemingly trivial thing: waiting for a child process
to finish, with a timeout.
On Windows, this boils down to a single WinAPI call. I don't know much about
Windows, but the code looks okay to me. There is a minor issue of timeouts
being capped at ≈49 days, which I reported:
https://github.com/alexcrichton/wait-timeout/issues/23
On Unix, the algorithm is much more involved. I understand it, and I believe
it to be correct.
The crate calls into libc and WinAPI, so there are a bit of unsafe in here.
But it all looks all right to me.
This crate vendors various WinAPI libraries for i686. All it does is add
a library search path to Cargo, pointing at a directory full of .a files
(static libraries).
I didn't actually verify where the libraries come from, and if they match
their origin; that's why I cap thoroughness at "low", and rating at
"positive".
This crate vendors various WinAPI libraries for i686. All it does is add
a library search path to Cargo, pointing at a directory full of .a files
(static libraries).
I didn't actually verify where the libraries come from, and if they match
their origin; that's why I cap thoroughness at "low", and rating at
"positive".
© bestia.dev 2023, MIT License, Version: 2023.608.1636
Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/
This is an implementation of Adler-32 checksum. It has no
unsafe, and thecode is quite simple. The only complicated part is the algorithm itself, but
there is a big comment explaining what's going on, and the structure of the
code matches the explanation. I can't vouch the implementation is bug-free,
but I'm sure it's sound and isn't malicious.
Thoroughness is "high" because I read the whole crate quite attentively, but
understanding is still "medium" since I didn't quite follow the math that
enables vectorization in this crate.