Bernd RodlerandClaude Opus 4.8
90c1176f93
Found live, not from a test: sent a genuinely signed+encrypted message through the real composer, opened it in Sent, and the banner showed only "Encrypted message" - no signature row at all, despite both Sign and Encrypt having been checked and the body decrypting correctly. Root cause is a race, not a crypto bug. onRenderEmailBody (which fetches the blob, decrypts, verifies the inner signature, and persists the full status) and EmailBanner (a separate plugin UI slot) mount independently. The banner read persisted status exactly once, in a useEffect keyed only on email.id. If that read fired before the async decrypt+verify pipeline finished writing, the banner fell back to a header-derived guess: it can see from the OUTER envelope's Content-Type that a message is encrypted, but has no way to know it is ALSO signed, since that only becomes knowable after decryption completes. This is more than cosmetic. The same race could just as easily hide an INVALID signature - a tampered message or wrong signer - behind the generic "Encrypted message" banner, purely because of timing, with no indication anything needs attention. Fix: track whether the initial read came from a real persisted value or from the header-only fallback. Only in the fallback case, poll briefly (150ms x 20 = 3s) for the real result to land - the same pattern unlockNow already uses after a manual key unlock, generalized to the initial mount. Once persisted state exists, stop. Verified in the real browser: re-sent and re-opened the same signed+ encrypted Sent message after this fix, banner now shows both rows - "Decrypted" and "Valid signature by bernd.rodler@sandbox.vnc.de - self-signed" (amber, correctly, since the spike cert is self-signed and fix 1's selfSigned flag is doing its job). Two source assertions added to verify-fixes.mjs. 51 unit assertions, 28 round-trip assertions, all passing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>