Veratex: Sanitize decrypted mail body before rendering as HTML to prevent stored XSS

[veratex-ai]

Resolves #2.

Summary

mails.ts rendered decrypted mail bodies via innerHTML with no sanitization, letting any friend send HTML/script payloads that execute in the recipient's webview (stored XSS with local gRPC access); fixed by sanitizing with DOMPurify before assignment.

Verification

• Test suite: no test suite found in the repository

Results above were observed by Veratex re-running each suite in its sandbox; the agent's own report is never used for a merge decision.

Risks to review

• This repo has no automated test suite, so verification here was a production build plus manual confirmation that DOMPurify.sanitize is invoked on the mail body in the compiled bundle — not an automated regression test.
• Added a new runtime dependency (dompurify) per the issue's own suggestion; it is a widely-used, actively maintained sanitizer with no other runtime deps.

---

Opened automatically by Veratex (runner: e2b). This branch was produced by an AI agent from the linked issue.

[veratex-ai]

Veratex prepared this fix but did not auto-merge because the agent flagged it for human review.

mails.ts rendered decrypted mail bodies via innerHTML with no sanitization, letting any friend send HTML/script payloads that execute in the recipient's webview (stored XSS with local gRPC access); fixed by sanitizing with DOMPurify before assignment.

Risks:

• This repo has no automated test suite, so verification here was a production build plus manual confirmation that DOMPurify.sanitize is invoked on the mail body in the compiled bundle — not an automated regression test.
• Added a new runtime dependency (dompurify) per the issue's own suggestion; it is a widely-used, actively maintained sanitizer with no other runtime deps.