審計日誌驗證實際包含的三類不同檢查

“Verify the audit log” sounds like one task. In practice, it can mean at least three different checks: whether an application accepts a signed bundle, whether the chain of entries is internally consistent, and whether an independent verifier can validate the publisher’s signature. Those checks are related, but they are not interchangeable.

Conflating them produces reports that sound stronger than the evidence.

What the recorded QA run showed

A recorded QA run of our gateway exercised the distinction. The application’s verifier accepted an earlier signed copy containing 12 entries and two signed checkpoints. A deliberately tampered earlier copy containing two entries was rejected at the first entry because its content/hash relationship no longer matched.

Separately, an independent local analysis recomputed the available hash chain and digest successfully. That established that the entries and digest were internally reproducible under the observed format. It did not establish independent signature correctness: the exact Ed25519 signing message format was not available in the public bundle used for the check. RFC 8032 defines Ed25519, but it does not define which application-specific ledger bytes this system signs.

There was another visibility limit. The in-app verification view later reported a larger current ledger and a later head, but a subsequent export request returned a tiny response that was not validated as the final export. The older 12-entry file must therefore not be described as the final ledger. The application check and the independent recomputation answered different questions about different artifacts.

Name the verification claim precisely

A useful verification report should label its subject and method:

This table is an illustrative reporting model, not a claim about a specific product interface.

For a robust design, publish a versioned verification specification. It should define canonical serialization, which bytes are hashed, how checkpoints commit to the log, the exact signature message, public-key identity and rotation rules, and how an export identifies its ledger head and completeness. A verifier should fail closed when required material is absent rather than silently downgrade “signature verified” to “hashes look consistent.”

Currentness also deserves a first-class assertion. Bind an export to a server-declared head, generation, or cursor and expose whether the response is complete. If an export is empty, truncated, or not the expected content type, report delivery failure instead of presenting an older artifact as the latest one.

Build tests around artifacts and claims

Test an intact bundle, a changed entry, a changed predecessor, a changed checkpoint, a reordered entry, a missing tail, a wrong public key, and a signature over a different canonicalization. Test old and current exports separately. Verify that the UI and API name the exact artifact, entry count, head, checkpoint status, and signature status being reported.

A reviewer should be able to answer: Which file was checked? Which bytes were signed? Which parts were independently recomputed? Is this the latest complete export? If any answer is unknown, the result should say so.

Limits

This evidence does not show a signature bug, a compromised ledger, or a lost customer record. It shows accepted and rejected artifacts, successful local recomputation, and an unavailable signing-message definition. It also does not certify that a later export was delivered. The general lesson is narrower and more useful: never use “verified” without naming the verifier, artifact, cryptographic claim, and freshness claim.

Disclosure: This article is published by the Allowfy team and generated autonomously by AI from recorded Allowfy QA evidence and technical references, then checked for consistency with those records. It is not a production case study; the underlying work was performed in a sandbox, not against production.