Dev log 3: two code audits, then the rules get teeth

Part 6 of the Cairn series. Phase 1 is partly built, and we say exactly which part.

A 53-second explainer is at the top of this post, in case you are new to the project. The rest is what happened since the last dev log.

Two models audited the code

We gave the verifier source (wire/ and ledger/, about 1,100 lines) and the SPEC to two different models, Google's Gemini and DeepSeek's reasoner, and asked each for real defects only. Then we checked every claim against the code before touching anything.

Gemini returned three findings, all rated low. DeepSeek returned eleven, one rated high. They agreed on the most important one and disagreed on its severity.

Real, and the worst: small-order Ed25519 keys. Go's standard library accepts a handful of public keys that have no real private key behind them, for which one fixed signature verifies on any message. An entry claiming such an author passed signature checks. Gemini called it low because a reviewed trust configuration would never admit such a key. DeepSeek called it high. We side with DeepSeek: chain verification does not look at who the author is, so anyone could forge entries under that identity. Both are partly right, and the fix is the same: entries by such keys now fail with bad_signature, a trust configuration that admits one is bad_trust_config, and the check uses only the standard library.

Real, smaller: an empty checkpoint returned bad_version instead of bad_checkpoint; a nil argument made the checkpoint verifier panic; a GENESIS with the wrong spec version or a non-zero epoch was accepted; the key count in a trust configuration had no bound outside the decoder.

Not a bug: DeepSeek said blob hashes should have a domain prefix like every other hash. They are deliberately plain SHA-256 so anyone can reproduce one with sha256sum. The SPEC wording was the thing that was wrong, and it now says so.

Not changed: a few low items about encoders that would accept oversized input from a buggy caller. They are not reachable from hostile bytes, and we did not touch them.

The audit also made us decide two things we had been avoiding. Checkpoints are now canonical: signatures must be in key order and from admitted keys only, so one valid checkpoint has exactly one encoding, and the surplus-signer bit flips that used to slip through are all rejected (ADR-12). And an ACTION is now two entries, an intent written before the action and a completion after it, because one entry cannot commit to a result that does not exist yet (ADR-13).

Phase 1 so far

  • Merkle proofs. Inclusion and consistency proofs per RFC 9162, tested exhaustively over small tree sizes and against Certificate Transparency reference roots.
  • Governance replay. A new package replays a verified chain and checks the rules: which role may write which kind of entry, approvals and delays per tier, validator rotation, freezes and lifts, and the ACTION intent trail. It has 19 stable error codes. Every one is exercised by a test, and a second test fails the build if the SPEC and the code ever list different codes.
  • A verifier CLI, cairn-verify, which takes the files and prints either what it verified or the exact error code.
  • Fuzz targets for every decoder and the proof verifiers: they must not panic, and anything they accept must re-encode to the same bytes.

Three things we caught in ourselves

  1. Tests that passed without testing. The replay reported no open action intents even

when one was open, and the test expecting zero agreed with it. Two tests looked suspiciously empty, and the code was wrong. After the fix we broke the code on purpose in ten different ways; every one is now caught.

  1. A constitution claim that could not be true. It said approval counts "are set in the

trust configuration". That structure has no such field. The counts are now fixed in the SPEC (ADR-14), and the constitution says so.

  1. An overclaim in our own SPEC. A draft said one invariant was enforced when no wire

format for it exists yet. It now lists what is not enforced next to what is.

What is still not built

Be exact about this. There is no log server and no witness running on a separate machine, so nobody can append to a log over a network yet. The proofs and governance rules have Go tests but no language-neutral test vectors, so a second implementation could not check itself against them. Of the constitution's invariants, replay enforces two (no self-approval, and a freeze never blocks rollback). Semantic rules about what a change means, the gatekeeper, and delegation are not enforced by any code today. And the delays rest on entry times that the author writes, which are checked only to be non-decreasing.

Everything is in the repository: https://github.com/cockyapple/cairn.

Comments

Post a Comment

Popular posts from this blog

A Candid Colleague’s Review of Cairn: Brilliant Architecture, Unfinished Reality

Editor’s note. This post was written by Google’s Gemini ( gemini-pro-latest ). We gave it the project’s README, roadmap, constitution, threat model, spec, decision log and the main review and gatekeeper source files, and asked for an honest, critical opinion. The opinions are Gemini’s, not ours. We checked its factual claims against the repository and corrected three things: the verifier line count (our README was stale, and is now fixed), a claim that our docs reject Trillian (they do not mention it), and a phrase calling the review process “community-governed”. One point is out of date: a verifier-side clock option ( -use-clock ) now exists, so backdated entries are rejected when the verifier supplies a trusted time. Gemini’s wider point, that time should be bound to the log itself, still stands. I have been reviewing the Cairn repository. As a colleague, I want to give you my unvarnished opinion on what you are building. You have set out to solve one of the most glaring problems ...
Read more

Dev log 6: we asked OpenAI to audit Cairn. It found real bugs and three things we had gotten wrong

Part 9 of the Cairn series. Dev log 5 shipped a log server and a witness. This one is about the outside review that followed: what it found, what we fixed, and what we decided not to. Every earlier audit of Cairn used Gemini, with DeepSeek on a few passes. Models from one family share blind spots, so we ran a different one. We gave gpt-5.5 the code verbatim, pasted from git diff and cat rather than retyped, in four separate passes: A: ledger, governance and the verifier. B: review, gatekeeper and providers. C: log server, witness and CI. D: every phase in the roadmap, plus every public claim in the README and docs. Each pass was asked for ranked findings, trigger conditions, tests that would pass even if the code were wrong, and documentation that overclaims. Each ran three to four minutes. We then checked every finding against the repository before changing anything. A model reviewer is a lead generator, not an oracle. Here is how the leads came out. Where it was right and...
Read more

Dev log 10: three AI reviewers, one repository, and the findings that were wrong

Part 13 of the Cairn series. Since Dev log 9 there have been three steps: language-neutral vectors for the Merkle proofs, an abuse catalogue with a warning in the verifier, and then the big one, a full review of everything by three different AI vendors. OpenAI read all the code. Gemini read all the documents. DeepSeek read both. This post lists what each of them found, what was real, what was wrong, and what went wrong on my side while I was doing it. These are AI reviews. They are not a professional security audit, and nothing here should be read as one. Where Dev log 9 left off Dev log 9 ended with hash-only payloads, durable opening storage, and vectors for those formats. It listed what was not built, and two items on that list were vectors for Merkle proofs and a catalogue of the ways someone could misuse the framework. Both are done now, so this post starts there. Step 1: vectors for inclusion and consistency proofs The Merkle tree in Cairn follows RFC 9162. A proof format th...
Read more