docs(smime): record finding 10 (banner race) in the audit

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 12:35:33 +02:00
parent 90c1176f93
commit a9af816012
1 changed files with 10 additions and 0 deletions
@@ -60,6 +60,16 @@ Every layer of the delivery path has now been exercised at least once:

 One near-miss during that last step, worth a minor UX note rather than a security finding: the PKCS#12-file-passphrase field has a "leave blank if the file has none" placeholder and no required marker, while the storage-passphrase field is marked required. The first attempt left the file passphrase blank and got pkijs's literal MAC-verification error — *"Integrity for the PKCS#12 data is broken!"* — which is the **correct** response to a wrong passphrase, not a bug. Most real CA-issued `.p12` files do have a passphrase, so the placeholder invites the mistake. Worth revisiting the copy in a later UI pass; out of scope for this audit.

+### Finding 10 — banner slot can silently miss a resolved signature (found live, fixed)
+
+The end-to-end send/receive test surfaced a real bug the crypto-level round trip could not have caught: sent a genuinely **signed+encrypted** message through the real composer, opened it in Sent, and the banner showed only *"Encrypted message"* — no signature row — despite both checkboxes being on and the body decrypting correctly.
+
+**Root cause — a race, not a crypto bug.** `onRenderEmailBody` (decrypts, verifies, persists the full status) and `EmailBanner` (a separate plugin UI slot) mount independently. The banner read persisted status **exactly once**, on mount. If that read fired before the async decrypt+verify pipeline finished writing, it fell back to a header-derived guess that can see the message is encrypted but has no way to know it's *also* signed — that's only knowable after decryption.
+
+**Why this is more than cosmetic:** the same race could just as easily hide an **invalid** signature — a tampered message, wrong signer — behind the generic "Encrypted message" banner, purely on timing, with no visual indication anything needs attention.
+
+**Fixed:** the initial read now distinguishes a real persisted value from the header-only fallback, and only in the fallback case polls briefly (150ms × 20 = 3s) for the real result — the same pattern `unlockNow` already used after a manual key unlock, generalized to the initial mount. Verified live: re-opened the same Sent message after the fix, banner now shows both rows correctly ("Decrypted" + "Valid signature by bernd.rodler@sandbox.vnc.de · self-signed").
+
 ## Findings

 | # | Severity | Finding | Location |