Audit chela yourself

This chapter gives you the grep commands and file pointers to check chela's claims yourself: no hidden dependencies, no unsafe footguns, secrets wiped after use, reproducible builds.

Security audit

1. No third-party dependencies in the crypto core

The cryptographic core - chela-primitives, chela-field, chela-sss, and chela-bip39 - has zero third-party crate dependencies. SHA-256, GF(2^8) arithmetic, the BIP-39 wordlist, and the OS RNG wrapper are all hand-written. You can verify the dependency graph by listing every crate name in the lock file and auditing each one, or by inspecting each crate's Cargo.toml directly.

grep '^name = ' Cargo.lock | sort -u

Cargo.lock

2. unsafe_code is denied workspace-wide

#![deny(unsafe_code)] is set in Cargo.toml at the workspace level, so any crate that uses unsafe must explicitly opt in with #![allow(unsafe_code)]. Exactly five files do so, each for a narrowly scoped reason: the OS RNG call, the volatile-write primitive, the polynomial-coefficient wipe in chela-sss, the TUI terminal raw-mode toggle, and the WASM FFI boundary. You can enumerate all opt-in files with:

grep -rn 'allow(unsafe_code)' chela-*/src

The five opt-in files:

• chela-primitives/src/rng.rs - OS RNG syscall
• chela-primitives/src/zeroize.rs - volatile write for zeroizing secrets
• chela-sss/src/lib.rs - one &mut [Gf256] → &mut [u8] cast to volatile-wipe the polynomial coefficients after split, sound because Gf256 is #[repr(transparent)]
• chela-tui/src/term.rs - terminal raw-mode ioctl
• chela-wasm/src/lib.rs - WASM FFI boundary

3. Secret-bearing buffers are wiped via volatile_set

A compiler is permitted to optimize away a zeroing write to memory that it can prove is never read afterward. chela uses volatile_set - a pointer write through a volatile cast - to force the write to take place even when the optimizer can prove the buffer is dead. You can find every location where secret material is wiped with:

grep -rn 'volatile_set\|.zeroize()\|impl Drop' chela-*/src

The primitive: chela-primitives/src/zeroize.rs

4. Pinned third-party GitHub Actions

Every GitHub Actions workflow in the repository pins third-party actions to a full 40-character commit SHA rather than a mutable version tag like @v4. A mutable tag can be silently moved by the action's maintainer - a supply-chain risk. Pinning to a SHA means the action cannot change under you without an explicit update to the workflow file. You can verify the pinning discipline with:

grep -rn 'uses:' .github/workflows/

Every line should end with a 40-character hexadecimal SHA, not a short version string. A @v4 or @main reference would be a finding.

Packaging audit

Reproducible builds

The release workflow builds chela in a fixed, pinned environment: a specific Ubuntu runner version, a pinned Rust toolchain, and a pinned set of GitHub Actions. Two independent builds of the same commit produce byte-identical artifacts. The workflow publishes a SHA256SUMS file alongside each release so you can verify the artifact you downloaded matches the artifact produced by CI.

.github/workflows/release.yml

Minisign signing

Every release artifact is signed with minisign - a small tool that uses Ed25519 signatures. The public key is embedded in README.md. Before running any chela binary you download, verify its minisign signature against the published public key. The exact minisign commands are in README.md under "Verifying a release."

README.md

Fuzz harness

chela-share includes a fuzz harness that throws arbitrary bytes at the share parser - the one place chela ingests externally supplied text - to prove it never panics, hangs, or over-allocates. Run it locally with cargo +nightly fuzz run, and for longer before a release. It found a panic in the share parser: the recovery_set_id field passed the four-byte length check but a four-byte non-ASCII value (e.g. "\u{FFFD}W") crossed a UTF-8 char boundary when sliced, crashing the byte slicer. The fix adds an is_ascii() guard before the slice.

chela-share/fuzz/

Ground truth

Got an AI agent?

Point it at AGENTS.md to orient it, then AUDITORS.md for the audit itself: each check there lists the exact command and the expected result, written so an agent can run it and diff the output - the same checks described on this page, in executable form.