Encrypted file attachments

Proposal, not an available feature. No network permission or new data collection is enabled. These RFCs are locally prepared; remote review/merge awaits the owner repository.

Current architecture

KDBX binaries are preserved on round trips but no attachment UI exists. The current full-buffer serializer and 8 MB file cap cannot stream arbitrary large attachments.

Design under review

First support small attachment binaries inside KDBX with strict remaining-vault quotas, safe names and no inline active-document execution. Encrypt before persistence and test with KeePassXC. For large files, use a separately reviewed versioned chunked AEAD container with authenticated ordering, total length and truncation detection; store only a protected reference/key in KDBX. Do not call this container native KeePass attachment interoperability.

Milestones

1. M1: small-file quotas, metadata sanitization and KDBX binary round trips
2. M2: download-only attachment UI plus corruption/quota/recovery tests
3. M3: separate streaming-container RFC and audited implementation before raising limits

Required acceptance tests

• Malicious names never escape the selected export directory
• Truncation/reordered chunks are rejected in a future streaming format
• Limit failures leave the previous encrypted vault intact

Limits

Large streaming attachments and proposed paid 1 GB storage are not available in this release.

Any implementation must preserve local unlock/export, add KDBX/KeePassXC regressions for crypto/format changes and update privacy disclosures before new data flows begin.

← All 41 workstreams