Encrypted instances report ciphertext size: listing and PROPFIND getcontentlength disagree with GET/HEAD #659

New issue

Closed

opened 2026-09-23 02:42:23 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-23 02:42:23 +00:00

Owner

Found in the #656 QA pass (v0.6.247). Reproduces on both dogfoods (files = enc, files-bao = openbao).

Matrix rows: §2 "Upload (button + drop)" / "Listing, sort, view toggle"; §7 "WebDAV mount".

Steps

Upload small files into _qa (button on files, drop on files-bao).
Read the size column. Then compare PROPFIND, HEAD and GET for the same file.

Expected: every surface reports the plaintext size the user uploaded.

Seen

File	Real bytes	UI list	PROPFIND `getcontentlength`	HEAD `Content-Length`	GET body
qa-small.txt (files)	32	3.2 KB	3248	—	32
qa-note.md (files)	55	3.2 KB	3271	—	55
qa-doc.pdf (files)	590	3.7 KB	3806	—	590
qa-drop.txt (files-bao)	24	3.2 KB	3240	24	24

The constant ~3.2 KB offset is the encryption envelope. HEAD and GET are correct; PROPFIND and the web listing report the stored (encrypted) object size. Protocol and UI disagree about the same file.

Why this matters beyond cosmetics

WebDAV sync clients (rclone, Finder, Cyberduck, the planned desktop client's ETag/size change detection) compare PROPFIND size against what they download. Every file on an encrypted instance will look size-mismatched: a false corruption signal, or needless re-transfers.
Small files look ~100× bigger than they are.
Probably also skews the per-user storage meter and quota accounting (not yet verified).

Why CI didn't catch it: interop-rclone (passed fresh at v0.6.247 in this pass) boots an in-job cairnd with unencrypted posix storage, so the envelope never exists there. Worth checking whether interop-enc asserts PROPFIND size equals GET length; it is dispatched later in this pass.

Screenshot: 659-ciphertext-size.jpg (outputs folder)

Found in the #656 QA pass (v0.6.247). Reproduces on **both** dogfoods (files = enc, files-bao = openbao). **Matrix rows:** §2 "Upload (button + drop)" / "Listing, sort, view toggle"; §7 "WebDAV mount". **Steps** 1. Upload small files into `_qa` (button on files, drop on files-bao). 2. Read the size column. Then compare PROPFIND, HEAD and GET for the same file. **Expected:** every surface reports the plaintext size the user uploaded. **Seen** | File | Real bytes | UI list | PROPFIND `getcontentlength` | HEAD `Content-Length` | GET body | |---|---|---|---|---|---| | qa-small.txt (files) | 32 | 3.2 KB | 3248 | — | 32 | | qa-note.md (files) | 55 | 3.2 KB | 3271 | — | 55 | | qa-doc.pdf (files) | 590 | 3.7 KB | 3806 | — | 590 | | qa-drop.txt (files-bao) | 24 | 3.2 KB | **3240** | **24** | 24 | The constant ~3.2 KB offset is the encryption envelope. **HEAD and GET are correct; PROPFIND and the web listing report the stored (encrypted) object size.** Protocol and UI disagree about the same file. **Why this matters beyond cosmetics** - WebDAV sync clients (rclone, Finder, Cyberduck, the planned desktop client's ETag/size change detection) compare PROPFIND size against what they download. Every file on an encrypted instance will look size-mismatched: a false corruption signal, or needless re-transfers. - Small files look ~100× bigger than they are. - Probably also skews the per-user storage meter and quota accounting (not yet verified). **Why CI didn't catch it:** `interop-rclone` (passed fresh at v0.6.247 in this pass) boots an in-job cairnd with **unencrypted posix storage**, so the envelope never exists there. Worth checking whether `interop-enc` asserts PROPFIND size equals GET length; it is dispatched later in this pass. **Screenshot:** `659-ciphertext-size.jpg` (outputs folder)