Subject
adler2 is a clean-room Rust implementation of the Adler-32 checksum, the
integrity check used by the zlib compression format. The crate is a maintained
fork of the archived upstream adler crate. The public API exposes an
Adler32 struct (with Hasher impl), a convenience adler32_slice
function over a byte slice, and an adler32 function over any BufRead.
The crate supports no_std (with default-features = false) and has zero
runtime dependencies; the only declared dependency is the optional
rustc-std-workspace-core, gated behind the internal rustc-dep-of-std
feature for libstd integration. Justifies impl-algorithm.
Methodology
The audit examined the published adler2-2.0.1 crate against its VCS source
at the commit recorded in .cargo_vcs_info.json on github.com/oyvindln/adler2.
The diff between contents/ and vcs/ showed only the expected cargo
normalisations (rewritten Cargo.toml, addition of .cargo_vcs_info.json
and Cargo.lock, removal of .git, .github, .gitignore); no source
files differ. The crate ships no binaries and no compiled artifacts
(justifies has-binaries), no build script (build = false in Cargo.toml,
no build.rs, no proc-macro entry points; justifies has-build-exec), and
cargo crates have no install-time hooks (justifies has-install-exec).
The source tree consists of two files: src/lib.rs (public API and tests)
and src/algo.rs (the core compute routine). Both were read end-to-end.
The crate is annotated #![forbid(unsafe_code)] at the root, so the
compiler guarantees no unsafe blocks, raw-pointer manipulation, or FFI
exist anywhere in the crate (justifies uses-unsafe).
The codebase was reviewed for network I/O (std::net, reqwest, ureq,
HTTP clients), process spawning (std::process, Command), dynamic code
execution, environment-variable access (std::env), filesystem operations
(std::fs, File::open), thread spawning, async runtimes, and
cryptographic libraries. None were found. The adler32 function accepts a
BufRead, but the crate does not itself open files; the caller chooses the
reader (justifies uses-filesystem, uses-network, uses-exec,
uses-environment, uses-concurrency, uses-crypto, uses-jit,
uses-interpreter). Adler-32 is a non-cryptographic checksum; the crate
neither uses nor implements cryptography (justifies impl-crypto). The crate
does not implement a parser, interpreter, JIT, protocol, data structure, or
concurrency primitive (justifies impl-parser, impl-interpreter, impl-jit,
impl-protocol, impl-datastructure, impl-concurrency).
Tools used: openvet 0.6.0 for workspace creation, claim/finding/annotation
management, and validation; diff (GNU diffutils) for the byte-level
comparison between contents/ and vcs/; git (2.51) for the upstream
checkout; grep/ripgrep for capability surveys.
Results
The comparison between the published crate contents and the upstream Git
repository shows that the code files match byte-for-byte; manifest
differences are limited to cargo's standard normalisation.
The implementation is a straightforward, integer-only port of the well-known
chunked 4-way Adler-32 algorithm described in Intel's Fletcher-checksum
paper. The chunk-size constant of 5552 * 4 is sized so that the per-lane
u32 accumulators cannot overflow before each modular reduction; the analysis
holds for all-0xff input, the worst case. All arithmetic is on plain
u32/u16 (no unsafe, no wrapping types), the algorithm is linear in
input length and uses constant auxiliary space, and there are no inputs that
can trigger pathological behaviour (justifies algorithm-impl-bounds,
algorithm-impl-safe). The output of the implementation matches the
published Wikipedia reference vector ("Wikipedia" → 0x11E60398), so the
implementation is functionally correct against an external reference
(justifies algorithm-impl-correct).
The crate ships a small in-crate test module in src/lib.rs
(justifies has-unit-tests). It has no tests/ directory of integration
tests, no quickcheck/proptest-style randomised tests, and no fuzz/
harness (justifies has-integration-tests, has-property-tests and
has-fuzz-tests). Unit tests cover the published Wikipedia reference
vector, all-zero/all-0xff/mixed patterns at multiple sizes that cross the
chunked path, resumption via from_checksum, and the BufRead path
(justifies algorithm-impl-tested).
There is no indication of malicious behaviour, obfuscation, exfiltration,
target-conditional payloads, or supply-chain tampering. The crate is
single-purpose and the implementation matches its documentation
(justifies is-benign).
Two low-severity quality findings are noted: limited testing depth — no
fuzz or property tests against a reference implementation (FINDING-1) —
and stale upstream-crate references in README.md and the html_root_url
attribute (FINDING-2). Neither affects runtime behaviour.
Conclusion
The crate is a small, single-purpose, unsafe-free implementation of a
standard checksum. Both findings are low-severity quality issues with no
runtime impact. Safe to deploy.