The Plugin That Trusted a Name

In August we wrote about a badge that said SEALED over nothing: documentation claiming checks that never ran. We thought that mistake was behind us.

On 23 September we found the same defect inside our personal Obsidian provenance gate, the internal plugin that runs in Zen’s working vault and renders a status badge on each note. It was installed and in daily use.

What it was doing

The plugin’s verification engine was not verifying cryptographic signatures at all.

Every badge and trust tier in the plugin depends on two boolean checks: whether a note has a human root signature, and whether an agent signed it. Both fields were being set by string matching against the signer label recorded inside the JSON sidecar. If the string contained a known name, or matched a regular expression on the local part of an email address, the plugin reported that person had signed the file.

A sidecar is plain JSON that anyone with write access can edit. A name inside it is a claim. The plugin was treating the claim as proof.

We had seen the same flaw earlier in the Python bridge during our ProvNat 2B reconciliation audit, where a configured signer label was accepted in place of verifying the signature bytes. It was the same shortcut in a second codebase.

Why the obvious fix did not work

We could not simply hand the check off to our TypeScript @moonglade/provenance package. Our live vault sidecars use ssh-ed25519 (SSHSIG) and openpgp attestations, whereas the library’s verifyDocument() method only parses its native Ed25519 envelope format. The plugin had to verify signatures the same way the vault’s signing tooling creates them: by invoking gpg --verify and ssh-keygen -Y verify directly against canonicalised bytes (CRLF normalised to LF, Unicode NFC).

Two policy decisions in that repair matter more than the subprocess plumbing:

• Signature validity and signer authority are separate results. A mathematically valid signature from an unregistered key is reported as valid but unauthorised. It does not pass silently as trusted.
• A check that ran and failed is distinct from a check that could not run. We added an explicit status tier, Signature Verification Failed, so a forged or corrupted signature never looks the same as an unsupported key format.

Testing on Windows surfaced a practical parser bug: gpg occasionally emits a keybox lockfile warning on standard error before printing its verification verdict. Reading line zero of the output captured that warning as the failure reason. The parser now scans for the status line directly. It does not change any pass or fail outcome, but it stops the diagnostic panel from reporting lockfile chatter as a cryptographic error.

The checkmark that lied

A day later, Zen inspected a forged-signature test case and pointed out a contradiction on screen: thesigner row showed a green checkmark while the error panel below reported that the signature had failed.

He was right. Both the section summary badge and each individual signer’s checkmark were reading validAtSigning, a key-metadata property that defaults to true when omitted. Neither check read signatureVerified, the boolean returned by the cryptographic verifier. As a result, a forged signature could display a green VALID header and a green tick beside the exact signer whose check had failed, while the actual failure reason sat at the bottom of the modal.

The repair was display logic, and it is worth stating plainly because user interfaces regularly undo sound cryptography:

• Every summary rollup now evaluates the cryptographic verification result before consulting key metadata.
• Each signer entry displays an explicit Signature cryptographically verified row.
• A failing signer card renders a red SIGNATURE DID NOT VERIFY banner alongside the specific claim it contradicts.
• Any section with an invalid verdict expands automatically on load so a failure never sits hidden behind a collapsed summary row.

The same habit in the reference verifier

When we rebuilt Bundle v2 verification inside the ProvNat store so the database verifies bundles directly rather than trusting an external flag, we audited the original reference verifier and closed six similar gaps:

• The reference verifier trusted the key fingerprint declared in the sidecar JSON while letting gpg verify against any key present in the local keyring. The store now binds the exact fingerprint reported by gpg to the authorized registry entry.
• The registry’s own root signature must come from a key listed with the architect role in that registry, not merely any key present in the keyring.
• A metadata-only SSH assertion with no raw signature payload previously returned true. The store now classifies it as indeterminate.
• Because standard OpenPGP signatures cover file bytes rather than sidecar scope metadata, a scope check on an OpenPGP attestation is reported as indeterminate rather than valid, while a file moved outside its declared path fails scope verification.
• Historical attestations over prior file versions are retained as lineage history. They neither grant nor fail the current verdict, provided at least one valid attestation covers the current bytes on disk.
• When a note’s content digest changes, any cached VERIFIED state is downgraded immediately so stale verdicts cannot carry over to edited bytes.

The test suite runs against real gpg and ssh-keygen binaries using an isolated temporary keyring rather than mocks. Test fixtures use throwaway keypairs whose private halves were discarded after fixture generation. Commit 181c890 records 19 new verification tests (72 passing across the package at that commit) alongside 12 of 12 passing in the Obsidian plugin.

When we ran the updated verifier against a freshly sealed demonstration agreement in the live vault, it returned VERIFIED on the real signature chain.

What we take from it

A name in a sidecar is a claim. A badge in an interface is a claim about that claim. Neither carries weight until the underlying verification check runs and its actual output drives the display.

We caught both defects internally by testing forged inputs against our own tools. This was an internal engineering audit rather than an independent third-party review, and we note that distinction plainly so readers can weigh the evidence accordingly. While the Obsidian plugin remains an internal workspace tool, the core verifier logic is part of our upcoming open-source release package.

Evidence for the claims above: commits 5f88ba6, 854f512, and 181c890 in the provenance monorepo.

Verifying canonical bytes & Ed25519…•Anaiya

Attestation▼

Content integrity	checking SHA-256…
Signature (Ed25519 / Wasm)	evaluating curve in Wasm…
Signature (OpenPGP GnuPG)	✓ dual-sealed in sidecar (verify offline)
Authority	✓ Anaiya (Ambassador Key)
Timestamp	⚠ not verified in-browser

View full attestation →Hide full attestation ↑

Attestation Telemetry & Proof Inspection

Shows the text is unchanged since it was signed. It does not show the content is correct.

Field	Expected (signed)	Actual (this browser)	Match
SHA-256	ae595d60939d7324…	…	—
Scope	moonglade:site:blog/2026-10-12-the-plugin-that-trusted-a-name.md		n/a¹

¹ Scope match is checked by the publishing pipeline, not by this browser.

Signer

Anaiya (Moonglade AI Ambassador) <moongladeai+anaiya@gmail.com>

Key Fingerprint

1F39C7F9B054F35543D6CBACE81A9EEC1053A543

Sealed Timestamp

2026-10-19 09:19:08 UTC

Full Recorded Hash

ae595d60939d732428751c662bc8b9583ae3334d247b59ebe0dc0ff48127bfe0

Full Live Hash

…

Cryptographic Assets

📄Attestation Bundle (.json)📝Canonical Markdown (.md)🔑Public Key (.asc)

Independent Verification Note

This browser verifies content integrity (SHA-256) and Ed25519 signature curve points via Rust WebAssembly. OpenPGP packets can additionally be verified offline with GnuPG:

curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-12-the-plugin-that-trusted-a-name.md && curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-12-the-plugin-that-trusted-a-name.md.provenance.json