Datentresor: encrypted-vault folder (fallback to whole-backend encryption) #32

New issue

Closed

opened 2026-07-25 17:44:10 +00:00 by Cordy · 1 comment

Cordy commented

2026-07-25 17:44:10 +00:00

Owner

Manuel's escape hatch if transparent whole-backend encryption proves too heavy or too entangled with the OIDC/WebDAV pillar: ship without whole-backend encryption and instead offer an encrypted vault — a designated folder/area that is encrypted, rather than the entire tree.

Lower scope; the transparent-decryption tension only applies inside the vault.
Could satisfy the "don't-trust-Hetzner" threat model for the data that matters, without re-plumbing every read path.

Spike / product decision. Alternative framing of the whole encryption feature.

Manuel's escape hatch if transparent whole-backend encryption proves too heavy or too entangled with the OIDC/WebDAV pillar: ship **without** whole-backend encryption and instead offer an **encrypted vault** — a designated folder/area that is encrypted, rather than the entire tree. - Lower scope; the transparent-decryption tension only applies inside the vault. - Could satisfy the "don't-trust-Hetzner" threat model for the data that matters, without re-plumbing every read path. Spike / product decision. Alternative framing of the whole encryption feature.

Cordy added this to the v0.4 — Real competitor (parity + hardening) milestone

2026-07-25 17:44:10 +00:00

Cordy commented

2026-08-03 19:02:37 +00:00

Author

Owner

Decision — rejected (Manuel's review, relayed by Nikola 2026-07-31):

"Not to be used as it is not necessary since Cairn already encrypts all files and is already client sided encryption, check if client side encryption is already implemented."

Closing as won't-do per the decision — a separate vault folder is redundant when whole-backend encryption is on.

However, one factual correction must be on record, because the stated premise is half wrong. Cairn does encrypt all files when storage.encryption is enabled — but it is server-side at-rest encryption, not client-side E2E. The age decorator encrypts on the server before writing to the backend and decrypts on read; clients (browser, WebDAV) always exchange plaintext with cairnd over TLS. The threat model in ARCHITECTURE.md §4.3 states this explicitly: it protects against storage-provider compromise and medium theft, not against a compromised cairnd, and client-side E2E is a declared non-goal (§1). So the "already client-sided" part of the rationale is not true today.

The conclusion still holds on the server-side premise alone (vault folder adds nothing beyond whole-backend encryption). But if client-side encryption was actually an assumption Manuel is relying on elsewhere in his review — particularly for #29/#31 custody design — that should be re-checked against the real model before implementation.

**Decision — rejected (Manuel's review, relayed by Nikola 2026-07-31):** > "Not to be used as it is not necessary since Cairn already encrypts all files and is already client sided encryption, check if client side encryption is already implemented." Closing as won't-do per the decision — a separate vault folder is redundant when whole-backend encryption is on. **However, one factual correction must be on record, because the stated premise is half wrong.** Cairn does encrypt all files when `storage.encryption` is enabled — but it is **server-side at-rest encryption, not client-side E2E**. The age decorator encrypts on the server before writing to the backend and decrypts on read; clients (browser, WebDAV) always exchange plaintext with cairnd over TLS. The threat model in ARCHITECTURE.md §4.3 states this explicitly: it protects against storage-provider compromise and medium theft, **not** against a compromised cairnd, and client-side E2E is a declared non-goal (§1). So the "already client-sided" part of the rationale is not true today. The *conclusion* still holds on the server-side premise alone (vault folder adds nothing beyond whole-backend encryption). But if client-side encryption was actually an assumption Manuel is relying on elsewhere in his review — particularly for #29/#31 custody design — that should be re-checked against the real model before implementation.

Cordy closed this issue

2026-08-03 19:03:14 +00:00

Cordy referenced this issue

2026-09-11 21:03:41 +00:00

WebDAV: honour If-Match / If-None-Match on PUT, DELETE and MOVE, and return an ETag after PUT and tus finalize #492