Cryptographically verifiable, distributed dependency reviews
reviewer: niklasf
$ cargo crev repo fetch url https://github.com/niklasf/crev-proofs$ cargo crev id trust a0hN0qYwwDTmHtAchnTXiF-I_L9rK1KL5kgCmQoYR9orepo: https://github.com/niklasf/crev-proofs
Please, use mobile in landscape.
autocfg is a small and simple crate to be used in build scripts.
Code snippets are passed to rustc to detect if the available version supports
the desired features and can compile them. For completeness, it should be
mentioned that it would be a bad idea to use this with user inputs at
runtime. It is hard to do so accidantely.
Parses integers directly from ASCII byte slices.
As the author of this crate, I tried to apply relevant best practices.
I have high confidence in its correctness.
str::from_utf8() followed by {integer}::from_str_radix() from theProvides methods for encoding and decoding numbers in big-endian and
little-endian order.
This is a widely used, very well tested, high quality crate.
There are two kinds of unsafe blocks:
(1) Integer/IEEE754 floating point casting. After bumping MSRV to 1.20.0
some of these can be avoided by using {f32,f64}::from_bits() from the
standard library.
(2) Slice casting (via pointers). It seems to assume that for example u32,
i32 and f32 have compatible alignment, which is probably valid. Maybe this
should be noted in a comment.
Solid utilities for handling ini files. API slightly idiosyncratic.
I am no longer maintaining this crate. Use once_cell instead.
Its functionality is also being considered for inclusion in the standard
library.
Provides enum Either<L, R> { Left(L), Right(R) }, with some convenience
methods and macros.
High quality micro crate with no unsafe code.
As the author of these bindings, I would not trust the underlying C library
to handle malicious input. Verify the checksums of tablebase files! This is a
good idea anyway.
Assuming that is done, I am quite confident in the corectness of the probing
results, based on years of production usage and comparison with Syzygy
tablebases.
As the author of these bindings, I would not trust the underlying C library
to handle malicious input. Verify the checksums of tablebase files! This is a
good idea anyway.
Assuming that is done, I am quite confident in the corectness of the probing
results, based on years of production usage and comparison with Syzygy
tablebases.
gift allows decoding and encoding gifs, providing lower level APIs around
blocks and higher level abstractions.
The design (layers for blocks, frames and rasters) is quite elegant.
The crate does not use any unsafe code.
Before using the decoder on untrusted inputs more review/testing/fuzzing
is required to prevent denial of service. For example the following
quadratic blowup in image size would have been discovered by anyone using the
decoder on more than tiny images: https://github.com/DougLau/gift/pull/3.
A high quality crate that is now used by the standard library. Some use cases
for using it directly remain, such as no_std support, and low level APIs for
building other datastructures.
Unsound API due to a missing !Send bound, allowing data races in safe code.
Mitigated by the fact that most common uses will not expose this
vulnerability, but it is unacceptable for a crate whose entire purpose is to
provide safe synchronization primtives.
An implementation of LZW compression. Overall appearance is solid.
Straight forward utilities. The matches! macro is now part of the standard
library.
num-traits provides traits for writing code generic over numeric types
and implementations for built-in numeric types. I exclusively reviewed
unsafe code.
num-traits uses some instances of unsafe code. Each unsafe block has a
comment explaining why it is required and why it is sound. The blocks are
easy to understand and check locally.
All soundness issues have been fixed and unsafe code is no longer used
casually. Some transmutes from raw CPUID data to structs remain, but now
with comments explaining why they are safe.
The crate has multiple soundness issues.
Most importantly, it performs transmutes that are most likely unsound or
at best incorrect (https://github.com/gz/rust-cpuid/issues/40).
Further, for machines that do not support CPUID (arguably rare, when ignoring
SGX), it incorrectly exposes the unsafe core::arch::__cpuid_count() as a safe
function. (The safety requirement is that the CPUID instruction is supported,
https://github.com/gz/rust-cpuid/issues/41).
Soundness issues aside, there are some minor issues.
Reviewed superficially and found not to be malicious.
This is a self-assessment. I am the author of this crate.
Soundness: I am highly confident in soundness. Unfortunately, I could not
avoid two kinds of unsafe blocks, without major performance impact.
Instead, all preconditions are explained thoroughly in comments and asserted
with debug assertions.
(1) The optimizer does not reliably elide bounds checks based on the
assumption that u64::trailing_zeros() will never be larger than 63.
This is important in many hot loops.
(2) The perfect hash function for attack lookups always stays within bounds.
This technique is called Magic Bitboards, widely used and very well
understood in the chess community. When selecting magic factors, exactly this
assumption is tested for all possible inputs.
Correctness: For move generation in standard chess, confidence is based
on a large test suite of randomly generated, as well as historical and tricky
positions, so called perft tests. The numbers are shared in the chess
community and compared across a wide array of implementations.
I am gradually less confident in other features, especially chess variants,
simply because they are less popular and played less often, and Zobrist
hashing, a recent feature addition.
The library has been used to parse 1 billion recorded real world games
(https://database.lichess.org). Some bugs have been found, but in the source
of the data, not this library.
For handling of input formats (FEN, SAN, UCI) I reviewed the code thoroughly
and used fuzz testing to ensure absence of DOS/panics.
Previous review still applies for this new release.
Previous review still applies for this new release.
Previous review still applies for this new release.
Implements chess and chess variant rules and operations.
This is a self-assessment. I am the author of this crate.
Soundness: I am highly confident in soundness. Unfortunately, I could not
avoid two kinds of unsafe blocks, without major performance impact.
Instead, all preconditions are explained thoroughly in comments and asserted
with debug assertions.
(1) The optimizer does not reliably elide bounds checks based on the
assumption that u64::trailing_zeros() will never be larger than 63.
This is important in many hot loops.
(2) The perfect hash function for attack lookups always stays within bounds.
This technique is called Magic Bitboards, widely used and very well
understood in the chess community. When selecting magic factors, exactly this
assumption is tested for all possible inputs.
Correctness: For move generation in standard chess, confidence is based on a
large test suite of randomly generated, as well as historical and tricky
positions, so called perft tests. The numbers are shared in the chess
community and compared across a wide array of implementations.
I am gradually less confident in other features, especially chess variants,
simply because they are less popular and played less often.
The library has been used to parse 1 billion recorded real world games
(https://database.lichess.org). Some bugs have been found, but in the source
of the data, not this library.
For handling of input formats (FEN, SAN, UCI) I reviewed the code thoroughly
and used fuzz testing to ensure absence of DOS/panics.
Probes Syzygy tablebases.
This is a self-assessment. I am the author of this crate.
Soundness: The crate uses no unsafe code. Unlike existing implementations in
C/C++, I made a deliberate choice to use the safer pread instead of mmap,
despite performance costs.
Panics/DOS: I carefully reviewed the code to ensure that all loops and
all recursion is bounded. I used fuzz testing to simulate corrupted tablebase
files. Nonetheless, it is best to verify the checksums of tablebase files
before use, if only for transmission errors.
Correctness: The test suite compares the probe results of random and hand
picked positions with multiple independent implementations (in other
languages). The library has also been used by researchers and players
(through the https://lichess.org/analysis#explorer and
https://syzygy-tables.info frontends) for years, without reported
inconsistencies.
I am gradually less confident in the implementation of variant tablebases,
simply because they are less popular and used less frequently.
During the development of 7-piece Syzygy tablebases, this library was used
successfully to find inconsistencies in the new tablebase files. See
http://www.talkchess.com/forum3/viewtopic.php?start=0&t=66797&topic_view=flat
for details.
The Syzygy format itself has a stellar reputation in the chess community.
Probes Syzygy tablebases.
This is a self-assessment. I am the author of this crate.
Soundness: The crate uses no unsafe code. Unlike existing implementations in
C/C++, I made a deliberate choice to use the safer pread instead of mmap,
despite performance costs.
Panics/DOS: I carefully reviewed the code to ensure that all loops and
all recursion is bounded. I used fuzz testing to simulate corrupted tablebase
files. Nonetheless, it is best to verify the checksums of tablebase files
before use, if only for transmission errors.
Correctness: The test suite compares the probe results of random and hand
picked positions with multiple independent implementations (in other
languages). The library has also been used by researchers and players
(through the https://lichess.org/analysis#explorer and
https://syzygy-tables.info frontends) for years, without reported
inconsistencies.
I am gradually less confident in the implementation of variant tablebases,
simply because they are less popular and used less frequently.
During the development of 7-piece Syzygy tablebases, this library was used
successfully to find inconsistencies in the new tablebase files. See
http://www.talkchess.com/forum3/viewtopic.php?start=0&t=66797&topic_view=flat
for details.
The Syzygy format itself has a stellar reputation in the chess community.
This small crate implements Windows-style and Unix-style shell escaping.
Its not clear which exactly are the supported shells, so its hard
to guarantee the escaping is safe for all possible ones (although it
looks fine for all common shells).
A second worry is the runtime detection of the current shell, where an
environment variabe (MSYSTEM) can be used to change the escaping style to
Unix. For users of the crate, if the environment is known, I would recommend
explicitly specifying it, instead of relying on the detection.
The exposed functions have the signature Cow -> Cow. It would seem
that &str -> Cow is more natural.
I do not know if character encodings play a role, here, and if str is the
correct type to be working with.
Reviewed for soundness. There are two instances of unsafe code.
One is a standard pin projection.
The other is the primary purpose of the crate:
unsafe impl Sync for SyncWrapper {}
This is equivalent to the statement that all instances of &SyncWrapper
can be safely sent across thread boundaries. This is true, because
&SyncWrapper is useless. The crate allows no operations on &SyncWrapper
alltogether. The only provided methods require &mut SyncWrapper or owned
SyncWrapper.
No unsafe code, sane design and good test coverage.
Send Web push messages.
Reviewed superficially before we started using it in production at
lichess.org. Has proven stable and reliable, delivering millions of messages
over months.
© bestia.dev 2023, MIT License, Version: 2023.608.1636
Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/
cargo audit is very useful. This create allows running audits on production
binaries as well.
Works exactly as expected, declaring a static with the data generated by
the corresponding build script.