These reviews are from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.

1.1.0 (current) safe-to-run, does-not-implement-crypto

From google/supply-chain copy of chromium. Audited without comment by ChromeOS.

1.1.0 (current) unknown

From kornelski/crev-proofs copy of git.savannah.gnu.org.

Packaged for Guix (crates-io)

The current version of Ascii is 1.1.0.

1.0.0 (older version) unknown

From kornelski/crev-proofs copy of salsa.debian.org.

Only in debcargo (unstable). Changelog:

• Team upload.
• Backport upstream patch to fix doctest errors with Rust 1.68+ (bindings_with_variant_name lint changed to deny-by-default). (Closes: #1052964)

cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.

safe-to-run

This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…

does-not-implement-crypto (implies crypto-safe)

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.

crypto-safe

Implied by other criteria

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.

unknown

May have been packaged automatically without a review

---

This review is from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.

The current version of Ascii is 1.1.0.

0.9.2 (older version) Rating: Negative Thoroughness: None Understanding: High

by MaulingMonkey on 2019-07-29

UNSOUND: https://github.com/tomprogrammer/rust-ascii/issues/64 (I didn't catch this one) unsound? https://github.com/tomprogrammer/rust-ascii/issues/65

Lots of repeated unsafe. No debug_assert! s for uncheck codepaths. Unsound test code assumes gen_range meets it's safe API contract. Not fully reviewed.

Detail

File	Rating	Notes
src/serialization/ascii_char.rs	+1	thoroughness: low, understanding: high throughout
src/serialization/ascii_str.rs	+1
src/serialization/ascii_string.rs	+1
src/serialization/mod.rs	+1
src/ascii_char.rs	0	unsound test code?
src/ascii_str.rs	-1	UNSOUND - missing #[repr(transparent)]` !
src/ascii_string.rs	N/A	Unreviewed
src/free_functions.rs	N/A
src/lib.rs	N/A
.gitignore	N/A
.travis.yml	N/A
Cargo.toml	+1
Cargo.toml.orig	+1
LICENSE-APACHE	N/A
LICENSE_MIT	N/A
README.md	N/A
RELEASES.md	N/A
tests.rs	N/A

Other	Rating	Notes
unsafe	-1	UNSOUND, disappointing lack of debug_assert!s.
fs	+1?	Not present?
io	+1?	Not present?
docs	+1?
tests	+1?

src/ascii_char.rs

Line	Notes
22	This must contain every value between 0..=127 for soundness guarantees bellow.
476	unsafe { ... } - looks sound. case 1 handles 32..=126, case 2 handles 127, case 3 handles 0..=31. Not wild about this impl but looks valid. See https://en.wikipedia.org/wiki/Control_Pictures
498	unsafe { ... } - looks sound. 'a' > 'A'
509	unsafe { ... } - looks sound.
548	unsafe { ... } - looks sound. Duplicate logic, annoyingly.
557	unsafe { ... } - looks sound. Duplicate logic, annoyingly.
659	unsafe fn - looks good.
670	unsafe fn - disappointing lack of debug_assert!
678	unsafe { ... } - looks sound.
686	unsafe fn - disappointing lack of debug_assert!. transmute from u8 to #[repr(u8)] enum... I believe that's sound.
694	unsafe { ... } - looks sound.
702	unsafe fn - looks sound.
714	UNSOUND TEST CODE? no guarantee generic Gen actually generates within range. Gated behind "quickcheck" feature.
735	UNSOUND TEST CODE? no guarantee generic Gen actually generates within range. Gated behind "quickcheck" feature.

src/ascii_str.rs

Line	Notes
116	unsafe fn - looks good.
352	UNSOUND unsafe { ... } - AsciiStr is not #[repr(transparent)] !
359	UNSOUND unsafe { ... } - AsciiStr is not #[repr(transparent)] !
367	UNSOUND unsafe { ... } - AsciiStr is not #[repr(transparent)] !
384	scary transmuting impl_into! macro, audit all uses carefully
390	UNSOUND unsafe { ... } - AsciiStr is not #[repr(transparent)] !
397	UNSOUND unsafe { ... } - AsciiStr is not #[repr(transparent)] !
405	UNSOUND unsafe { ... } - AsciiStr is not #[repr(transparent)] !
410	I believed these invokes would be sound if AsciiStr was #[repr(transparent)], but https://github.com/tomprogrammer/rust-ascii/issues/64 proved me wrong.
668	unsafe fn - looks good.
676	unsafe fn - looks good.
689	unsafe fn - looks good.
701	unsafe fn - looks good.
713	unsafe fn - looks good.
724	unsafe fn - looks good.
734	unsafe fn - looks good.
746	unsafe fn - looks good.
756	unsafe fn - looks good.
764	unsafe { ... } - looks sound.
768	unsafe fn - disappointing lack of debug_assert!.
777	unsafe { ... } - looks sound.
781	unsafe fn - disappointing lack of debug_assert!.
793	unsafe fn - looks good.
800	unsafe { ... } - looks sound.
804	unsafe fn - disappointing lack of debug_assert!.
818	unsafe fn - looks good.

• Issue: High (github.com/tomprogrammer/rust-ascii/issues/64)

  Definite soundness issue

• Issue: High (github.com/tomprogrammer/rust-ascii/issues/65)

  Probable soundness issue