POVV Verified · case study

We audited our own verifier five times before we let it pass.

povv-verify is the small open-source tool anyone can use to check a POVV receipt offline, without trusting our servers. Before it could carry our first public certificate, we pointed POVV's Full Repo audit at it. It took five audits: the first four each found something real, the fifth came back clean.

1. Audit 01 · commit cfcda4f · 1 confirmed · 3 coverage gaps

   Anyone could forge a VERIFIED receipt

   A POVV receipt carries an Ed25519 signature and the URL of the key set to check it against. The CLI fetched that URL by default. So a forger could sign a fabricated receipt with their own key, publish their own key set, point the receipt at it, and get VERIFIED.

   The audit confirmed the fallback half (an unknown key id silently fell back to the first key) and flagged the receipt-directed fetch as coverage gaps. Reading the whole file confirmed the forgery path.

   Before

   else if (options.fetchKey && receipt.signature?.jwks_url) {
     const jwk = await fetchJwk(receipt.signature.jwks_url, receipt.signature.key_id);
   // ...inside fetchJwk:
   return keys.find((k) => k.kid === keyId) ?? keys[0];

   After

   const trustedUrl = options.jwksUrl || DEFAULT_JWKS_URL; // never the receipt's own URL
   if (!match) throw new Error(`Key "${keyId}" is not in the trusted key set at ${jwksUrl}.`);

   Fix: povv-verify 1.1.0 →

2. Audit 02 · commit 2b8a81e · 1 confirmed high · 2 coverage gaps

   Unsigned data could hide past the hash

   The receipt hash is computed over canonical JSON: keys sorted, objects rebuilt. The rebuild used plain assignment. For an own __proto__ member, which JSON.parse happily creates, acc["__proto__"] = x hits the prototype setter instead of creating a key, so the member vanished from the hashed bytes. Extra, unsigned content could ride inside a receipt that still verified.

   The same three lines lived in POVV's own server. Both sides were fixed together, and a read-only scan of all 41 JSON columns in production confirmed no stored payload contained such a member, so no existing hash changed.

   Before

   .reduce((acc, k) => {
     acc[k] = v[k];
     return acc;
   }, {});

   After

   .reduce((acc, k) => {
     Object.defineProperty(acc, k, { value: v[k], enumerable: true, writable: true, configurable: true });
     return acc;
   }, {})

   Fix: povv-verify 1.1.1 →

3. Audit 03 · commit aaa64f1 · 0 confirmed · 4 coverage gaps

   The “time anchor” proved nothing

   No confirmed findings, but four open questions about the Merkle anchor. Reading the code answered them: the root and the proof both came from the receipt, and nothing compared the root with an external witness. The README still said the anchor “fixes the verdict in time”. It did not.

   The fix was mostly honesty: the CLI now says the inclusion check runs against the receipt's own root and that no time anchor was checked. A malformed proof now returns false instead of throwing.

   Fix: povv-verify 1.1.2 →

4. Audit 04 · commit a2cd0b9 · 1 confirmed medium · 4 coverage gaps

   A fake receipt could print its own VERIFIED line

   Confirmed: the npm description still promised verification against an anchored checkpoint. One of the open questions turned out worse than it looked. Receipt fields reached the terminal unescaped, so a newline or an ANSI escape in a forged key-set URL printed an extra “RESULT: VERIFIED ✓”, or moved the cursor up and overwrote the real result. We reproduced it on the old version before fixing it.

   Before

   for (const e of result.errors) console.log(`    - ${e}`);

   After

   for (const e of result.errors) console.log(`    - ${printable(e)}`);
   // printable(): C0, C1, DEL, line separators and bidi overrides become \uXXXX

   Fix: povv-verify 1.1.3 →

5. Audit 05 · commit 494cd55 · 0 confirmed · 5 coverage gaps · certified

   Nothing critical or high left

   Five open questions remained. One was contradicted by the code, two were documentation precision, two were small hardening items. None was a way to fake a result, so the commit met the rules for a certificate: every eligible file read in full, zero failed reviews, zero confirmed critical or high findings. The remaining questions were answered in 1.1.4.

   Fix: povv-verify 1.1.4 →