Subject
uuid is a no_std-compatible Rust library for generating and parsing universally unique identifiers (UUIDs). It implements the formats defined in RFC 9562 — the nil and max UUIDs, the version 1, 3, 4, 5, 6, 7, and 8 variants, plus user-defined v8 — along with parsers for the simple, hyphenated, URN, and braced ("Microsoft GUID") textual formats. Each UUID version is gated behind a Cargo feature and pulls in its own dependencies only when enabled.
Methodology
The published crate contents were diffed against the upstream Git repository at the commit recorded in .cargo_vcs_info.json; all 23 source files match byte-for-byte and the only manifest difference is cargo's standard normalisation. All src/ files (~8500 lines including the four external/* integration modules) were read in full. Every unsafe block was located via grep and audited individually. The Cargo manifest, README, and lib.rs crate documentation were reviewed to confirm what each feature flag pulls in and to compare documented behaviour to the implementation. The test directory and fuzz target are not shipped in the crate but were inspected in the VCS checkout. The test suite was not executed.
Results
The diff between the published crate and the upstream Git tree shows the source files match byte-for-byte; the only manifest difference is cargo's standard normalisation. The crate ships no binary artefacts (justifying has-binaries), no build.rs, and is not a proc-macro crate, so there is no build-time or install-time code execution on consumers' machines (justifying has-build-exec and has-install-exec).
The crate is purely computational: a search for filesystem (fs::, File::), network (TcpStream, tokio, reqwest, hyper, UdpSocket), process (Command::, process::), and environment (std::env, env!) APIs returned no matches in src/ outside of using std::time::SystemTime for the now_v1/now_v6/now_v7 helpers. This justifies uses-filesystem, uses-network, uses-exec, and uses-environment. The crate does not implement an interpreter, a JIT, a protocol, a non-trivial data structure, or a non-cryptographic algorithm (justifying uses-jit, uses-interpreter, impl-interpreter, impl-jit, impl-protocol, impl-datastructure, and impl-algorithm).
Cryptographic hashing is delegated to the md-5 and sha1_smol dependencies in the v3/v5 modules. The crate's own code (src/md5.rs, src/sha1.rs) only calls update and finalize/digest and copies the first 16 bytes of the digest into the UUID. MD5 and SHA-1 are mandated by RFC 9562 for v3/v5 name-based UUIDs, where their cryptographic weakness is not load-bearing because v3/v5 UUIDs are deterministic identifiers, not security primitives. uses-crypto is true; impl-crypto is false.
Eight unsafe blocks were reviewed (src/error.rs:74, src/non_nil.rs:88-89, src/builder.rs:435, four sites in src/fmt.rs, and one site in src/macros.rs). Three classes appear: from_utf8_unchecked[_mut] on buffers known to contain ASCII (either previously validated UTF-8 input, or hex digits and ASCII separators written by the crate); core::mem::transmute between #[repr(transparent)] wrappers around [u8; 16] (the four formatter newtypes around Uuid, and &[u8; 16] ↔ &Uuid); and one transmute from a #[repr(C)] {u8, [u8; 36], u8} to a [u8; 38] byte buffer in encode_braced. All have safety justifications either inline or via the internal unsafe_transmute*! macros, all transmutes hold under Rust's repr-transparent/repr-C layout guarantees, and all from_utf8_unchecked* invariants hold. When the unstable zerocopy feature is enabled the transmute macros expand to zerocopy::transmute*!, which check the same invariants at compile time. This supports unsafe-safe, unsafe-documented, and unsafe-minimal.
Randomness for v4/v7 is taken from getrandom by default, with optional backends for rand (fast-rng/rng-rand) and, on wasm32-unknown-unknown, WebCrypto via wasm-bindgen (js). compile_error! enforces that at least one source is selected on wasm32-unknown-unknown. Random-bytes failures panic with a descriptive message rather than silently producing biased output.
Concurrency surfaces appear in three places: ContextV1 wraps an Atomic<u16> counter incremented with Ordering::AcqRel (RFC 9562 requires a 14-bit clock sequence; the result is masked accordingly); ContextV7 uses non-thread-safe Cell fields and is documented as such, with the shared instance wrapped in std::sync::Mutex via SharedContextV7; and ThreadLocalContext adapts thread-local storage. The thread-safety contract of each is documented on the type. This supports uses-concurrency, concurrency-safe, and concurrency-documented. The crate does not itself implement concurrency primitives — it uses existing ones — so impl-concurrency is false.
The parser (src/parser.rs) is const fn, dispatches on input length, decodes hex via two 256-byte lookup tables with a 0xFF sentinel for invalid characters, and is exercised by both unit tests and a libFuzzer fuzz target (fuzz/fuzz_targets/fuzz_target_parse.rs). This supports impl-parser, parser-impl-safe, parser-impl-tested, and parser-impl-correct.
Two low-severity quality findings were noted (FINDING-1, FINDING-2): a typo in a user-visible error message and an internal code comment, and an operator-precedence-dependent mask expression in encode_unix_timestamp_millis. Neither has a functional impact.
The crate ships in-source #[cfg(test)] modules (justifying has-unit-tests) and a cargo-fuzz harness in the upstream fuzz/ tree exercised by CI (justifying has-fuzz-tests). There is no tests/ directory of integration tests and no proptest/quickcheck use, justifying has-integration-tests and has-property-tests as false. The unsafe surface is exercised by the unit tests and miri-run CI jobs, justifying unsafe-tested. No malicious patterns, obfuscation, or unexpected side effects were observed, justifying is-benign.
Conclusion
The package implements RFC 9562 UUID generation and parsing without doing anything beyond what its description claims: no network, no filesystem, no process execution, no build-time hooks. Its unsafe usage is small, localised, and load-bearing for performance rather than gratuitous, and each block holds under review. Cryptographic operations are delegated to well-known crates and used only for the deterministic v3/v5 generators mandated by the RFC.