What Ed25519 Signing Actually Proves About a Test Result

TL;DR: An Ed25519 signature proves that a registered private-key holder signed an evidence record; it does not prove who approved it or that the reported result matches reality. Read how the kernel works.

A signed test result arrives and everyone relaxes. Stop there for a second. What did the signature actually establish, and what did everyone quietly add to the story?

A signature authenticates a signing act, not a whole software claim. Ranex signs evidence with Ed25519 and verifies it against a committed public keyring before admitting a record. That is worth having. It is also easy to over-read, so the useful part is drawing the line around it.

In this note

• A signature proves a narrow fact
• Signing does not authenticate approval
• Handle keys like a boundary
• Keep the open risk visible

A signature proves a narrow fact

Ed25519 evidence signing proves that the holder of a registered private key signed the record. The verifier has public keys only, so it can verify that signature but cannot forge one.

That is the core claim. Before an evidence record is admitted, Ranex verifies its Ed25519 signature against the keyring committed in the repository. A record without a valid signature from a registered producer does not get to become evidence merely because it has a plausible producer label. The trust root is visible for review rather than supplied from whatever working directory happens to be present.

Pair that with the other boundaries and the result is more useful. Evidence is bound to a subject digest, so the same command against a different commit does not prove the current subject. The committed catalog also binds a claim to the argv that can satisfy it, preventing a signed record of an unrelated command from satisfying a named claim. The kernel evaluates the resulting evidence against its gate rather than treating a signature as a PASS button.

Still, say the claim precisely. The signature proves a registered key holder signed a record. Subject binding and claim-to-command binding constrain what the record can satisfy. They do not turn a cryptographic signature into a general proof that every reported observation was true. The difference matters when a report says “tests passed” and your next question should be “what did this evidence actually observe?”

Signing does not authenticate approval

Signing does not prove who approved a result. In the current kernel, --approver is a plain string, so a producer can name anyone as the approver.

This is a known gap, not a footnote. No-self-approval compares the producer and approver strings, and the rule still does its job as a structural check. But the identities represented by those strings are unauthenticated. A valid evidence signature proves nothing about the person who reviewed, rejected, or approved the work. Do not tell your team that a signed record has solved human authorization when the repository says it has not.

Signing also does not prove the test result is true in the broad sense people want. The README names a sharp boundary: an approved, hash-correct dependency can still choose its own exit code. Dependency approval reduces hidden change; it cannot make third-party code truthful. A signature can establish which registered key signed a record of that outcome. It cannot force the dependency to report reality.

That is not an argument against signatures. It is an argument against asking one control to carry every trust decision. You need frozen tests, subject binding, claim-to-command binding, separate approval, and checks appropriate to the property you care about. Performance, accessibility, and security are not free consequences of a passing functional gate. They need their own gates if you want a claim about them.

The most dangerous sentence in an incident is “it was signed, so it was safe.” Signed by whom? Covering which subject? For which claim and command? Approved by which authenticated identity? If you cannot answer those questions, the signature may be real while the conclusion is far too large.

Handle keys like a boundary

Private signing keys belong outside the repository. Ranex keygen refuses to write a private key anywhere inside it, while the committed governance/producers.yaml keyring contains public halves only.

The README describes that file as the trust root. It is a mapping from producer names to public Ed25519 values, and review of that committed mapping is the control on it. This is a practical distinction. A repository can carry the information a verifier needs without carrying the material that lets an attacker forge a producer’s signature from the tree.

export RANEX_SIGNING_KEY=~/.config/ranex/worker.key
PYTHONPATH=src uv run python -m ranex.cli.main keygen --producer worker

That command path is not ceremony. A private key in the repository would make the committed trust root and the signing capability travel together, which defeats the separation. The delegated worker loop is also described as starting in an environment that refuses to hold the signing key. A worker can do work; it is not automatically trusted to sign its own success.

Use the same lens with your own signing setup. Where does the private half live? Who can read it? Which process holds it during a run? Which reviewed public keys are permitted to verify? A key system is not only an algorithm choice. It is the path from private authority to the process that gets to use it.

Keep the open risk visible

Same-UID key theft remains open. Ranex says its run path still reads the signing key before spawning, so anything running as the same user can take it; the stated advice is to use a scoped, spend-limited key.

That risk belongs beside the strength of public-key verification, not beneath it. The verifier cannot forge because it has only public keys. A process that can steal the private key is a different threat. Strong verification cannot undo a compromised signing environment after the fact.

The repository’s Status section marks signed evidence as working today, lists unauthenticated approver identity and same-user key theft among known gaps, and calls the project pre-release. Those are the claims to carry into a real review. The complete governed product is not all built, and the boundaries here are deliberately smaller than a promise of total safety.

For longer-lived evidence, pair signing with an append-only record. The hash-chained journal retains an ordered record and detects out-of-band row edits, though it has its own rollback and truncation gap. Controls stack because their failure modes differ.

Find one signed report your team relies on. Write down what its key proves, what its subject binding proves, and what it cannot prove about the approver or the observed system. That is not distrust. That is the beginning of a claim you can defend.

Questions people actually ask

What does Ed25519 evidence signing prove?

Ranex evidence signing proves that the holder of a registered private key signed the record; the verifier holds public keys and cannot forge it.

Does an evidence signature prove who approved a result?

Ranex does not authenticate approver identity because the approver value is a plain string, so a signature proves nothing about who approved it.

Where does Ranex keep evidence signing keys?

Ranex keeps private signing keys outside the repository because keygen refuses repository paths, while the committed keyring contains public halves only.

Try it. Break it. Tell me what broke. Read the Ranex repository, then trace one signing key and one conclusion your own pipeline makes from it.

Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records — the same fact gate the product enforces on code. It ships only after Anthony’s own review.