cargo could not read the manifest at all:
error inheriting `aes-gcm` from workspace root manifest's
workspace.dependencies.aes-gcm: failed to find a workspace root
All 25 dependencies are declared `workspace = true`, which resolves only
against a [workspace.dependencies] table, and the crate was extracted from a
monorepo without one. The versions here are the ones Cargo.lock had already
resolved, so this records what the crate was building against and chooses
nothing new — `cargo build --locked` leaves Cargo.lock untouched.
That got the manifest parsed and the library building, which exposed three
callers written against an ml-kem/ml-dsa that predates the pinned versions:
Encapsulate and Decapsulate are private at ml_kem's root and public at
ml_kem::kem, and MlKem768::generate needs KemCore in scope.
ml-dsa has no Ml_Dsa65, no VerificationKey and no SigningKey::generate.
Key generation is the KeyGen trait (MlDsa65::key_gen), the pair hands out
signing_key()/verifying_key(), and signing goes through signature::Signer
and Verifier.
ml-dsa is on rand_core 0.9 while ml-kem is on 0.6, so one thread_rng cannot
serve both. The ml-dsa side takes OsRng from ml-dsa's own re-export, via
unwrap_err, because OsRng is fallible in 0.9 and key_gen wants an
infallible CryptoRng. No new dependency.
integration_test's message list mixed [u8; 9], [u8; 27], [u8; 0] and
[u8; 1000] in one untyped array, which has no single element type. Typed
as [&[u8]; 4].
Both examples RUN, not merely compile: ML-KEM encapsulation round-trips,
ML-DSA signatures verify, HQC round-trips. 12 tests pass.
Worth knowing separately: src/ml_kem.rs, src/ml_dsa.rs, src/hqc.rs, src/pqc/
and src/hybrid/ are in no build target — lib.rs declares only symmetric, hash,
error and prelude. Those wrappers are dead files and would not compile as they
stand (src/ml_dsa.rs imports the same Ml_Dsa65 and VerificationKey that do not
exist). Post-quantum is reachable today only as the re-exported upstream
crates, without this crate's SecurityLevel/zeroizing layer over it.
github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
This repo shipped with no LICENSE, which makes it legally ambiguous the moment
it is public: absent an explicit grant, default copyright reserves all rights,
so a reader may look but not use — the opposite of what publishing it is for.
Original Hanzo work (single initial commit, no upstream lineage), so the terms
are ours to set, and the fleet already has one answer: the HIP-0137 dual offer
carried verbatim from the canonical files rather than retyped.
Co-authored-by: Hanzo Dev <[email protected]>
Post-quantum crypto crate (ML-KEM/FIPS 203, ML-DSA/FIPS 204, HQC, BLAKE3,
ChaCha20-Poly1305, AES-GCM, X25519, Ed25519, Argon2). 22 files, no history,
no remote, not on GitHub — invisible to every repo-shaped audit because it
had no .git to find.
Captured the org-level workspace root it depends on, plus the cargo defect
that made it unbuildable. See BACKUP-NOTE.md.
Co-authored-by: Hanzo Dev <[email protected]>
zooqueen
zeekayandHanzo Dev