Repository navigation
Verify encrypted Email storage on a separate native canary #5543
Description
🤖 Generated by the Agentic Engineer
Problem
Company Email must use transparent server storage encryption while ordinary mail clients continue reading messages normally. Before moving retained mailbox data, we need evidence that encrypted storage mounts and recovers safely on the deployed platform.
Expected outcome
Provide a reviewed, main-only, explicitly confirmed workflow that exercises a separate encrypted test volume using synthetic content and a test-only key. It must never select the Email claim or change its operational key, and it must fail closed when runtime evidence or ownership is incomplete.
Acceptance criteria
- An explicitly confirmed protected workflow is bound to its immutable reviewed main revision and refuses retries and other event/ref/repository combinations.
- The native test verifies the deployed storage and operating-system versions, actual encrypted volume identity, ordinary write/read, detach/remount, refusal with unavailable and incorrect keys, and successful recovery with the original test key.
- Every mutation and cleanup is restricted to resources created by this invocation. Existing claims, volumes, service credentials and operational keys are untouched. Interrupted runs retain enough identity for safe follow-up and never guess cleanup ownership.
- Tests cover false-positive runtime observations, key handling, ownership mismatches and cleanup failures. No private value appears in logs or public artifacts.
- Pass current-head CI, substantive review and protected merge, then record the actual main workflow result before claiming encrypted-storage readiness.
Part of #5387. Actual operational-key recovery remains #5540; this synthetic test does not replace it or migrate mailbox data.
Metadata
Metadata
Assignees
Labels
No labels
Type
Fields
Priority
High
Start date
None yet
Target date
None yet
Effort
Medium
Projects
- Status
Activity
chore: agent-claim #5543 nonce=3616c035a9bff6d0a8a3dd35c9a9a3c0
chore: agent-claim #5543 nonce=0776beca78640891df9bb32f088533ad
chore: agent-claim #5543 nonce=fe8a43e652e1af4bf82501ff23e06d02
chore: agent-claim #5543 nonce=a42b3f9c36b1ff1e83c463a562a69c20
devantler commentedon Oct 29, 2026
The protected canary source merged in #5551, with its exact merge-group checks passing. The approved first main-only native test is run 40874287889; it is queued behind production recovery and has not started a job yet.
Operational-key recovery is complete in #5540. Native encrypted-volume readiness, verified test cleanup and the mailbox cutover remain unverified until their actual acceptance results are collected.
chore: agent-claim #5543 nonce=c7ef6344730d1ab270847ed7fd87f1d8
devantler commentedon Oct 29, 2026
Completed by #5551 and the actual first main-only native canary 40874287889, job 123459442221. The source-bound, first-attempt workflow passed on the deployed storage/OS stack: encrypted volume identity, ordinary write/read, detach/remount, missing-key refusal, wrong-key refusal and recovery with the original test key. Its receipt reports
cleanup=VERIFIED; independent read-only checks also found the test namespace and backend volume absent.Current-head CI, substantive Codex review and protected merge preceded the native test. Only invocation-owned synthetic resources and a separate random test key were used. Operational-key recovery is complete in #5540. This completes the native canary slice; it does not activate production Email encryption or establish mailbox-data restoration and cutover, which remain in #5387.