Cryptographically verifiable, distributed dependency reviews
reviewer: dbrgn
$ cargo crev repo fetch url https://github.com/dbrgn/crev-proofs
$ cargo crev id trust ILvan_fvVdN8cSH8GC7kB_h-3W6xWnafsCUTpdoTxQ4
repo: https://github.com/dbrgn/crev-proofs
Please, use mobile in landscape.
Overall the code looks clean and easy to understand, with the exception of
the is_match / handle_text functions in lib.rs... Those are a bit hard to wrap
the head around and could probably be refactored for easier understanding.
Performancewise I have the feeling that a few allocations could be avoided,
but I didn't fully think through alternative implementations.
I'm one of the authors. This crate contains just types for serialization and is of low complexity. No unsafe. Using this in production.
I focussed my review on the linux
and persistable
modules, I did not take
a look at the sponge
module.
The code looks straightforward, even though I am not terribly familiar with
the POSIX file APIs. I did not spot anything obviously bad.
Pull requests created as part of this review:
This is mostly just a wrapper around thiserror_impl
, so not much to do
wrong there. I don't understand the undocumented private::AsDynError
trait
though, it doesn't seem to be used in any examples or tests.
I'm the author. I'd consider the codebase to be clean and readable. More reviews are obviously welcome.
This package with its 6 lines of code and no dependencies is reasonably simple
that I can claim that it's secure!
The crate is potentially unmaintained since the author did not react to two
license-related minor issues, but the project is arguably feature-complete.
© 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 a very small crate that encodes and decodes basic auth headers (which
is essentially just a base64
user:password
string). It might be handy insome situations.
The crate looks correct overall and is covered with tests. It could however
be made more efficient, there are a lot of allocations going on that could be
avoided (e.g. copying strings, taking strings instead of slices in an API,
collecting parts into Vec after splitting, etc). That's not an issue
at all for small, non-performance-critical projects, but it might be a minor
issue if you're performance-sensitive and do a lot of authentication
handling.