borg2: encrypt the repo-side cache/ objects (referenced-by-archive.*)
- Dominant language
- Python
- Stars
- 13.7k
- Forks
- 875
- Avg merge
- 11h 15m
- Merged PRs (30d)
- 192
Description
While reviewing `docs/internals/security.rst` against the code (#10233), we noticed that some repo-side store objects contain unencrypted metadata:
- `cache/referenced-by-archive.` — written by `borg compact` and `borg analyze` (`cache.py` `write_refs_cache()`, used via `compact_cmd.py` / `analyze_cmd.py`). These are plain msgpack'd lists of the object IDs an archive references, plus plaintext chunk sizes. Anyone who can read the store (e.g. the repo hosting party) can recover the object graph — which archives reference which chunks — and the size distribution from them.
- `cache/chunkindex-invalid` and `cache/checked-packs` — much less sensitive (flags/pack names only), listed for completeness.
- Related, same information class: the `index/` chunkindex fragments are also stored unencrypted (raw borghash serialization, only sha256-content-addressed) and map all chunk IDs to sizes and pack locations.
This contradicts the attack model in `docs/internals/security.rst`, which says an attacker with repo access cannot recover the object graph. Two ways to resolve:
1. Encrypt these objects (like archives/manifest/keys already are) — needs care for the `check`/`repair` paths that read them without a passphrase, and for the "authenticated" and "none" modes.
2. Or, if the metadata visibility is accepted as a documented trade-off (it clearly buys speed — e.g. the REST server can serve index fragments without any key material), adjust the attack model text in security.rst instead.
Related: #8386 (encrypt lock files) — its comment "This should be delayed until after everything else is encrypted" suggests treating this as part of one store-side-metadata-encryption effort; this issue can serve as the tracking point for the cache/ (and index/) part.
Contributor guide
Assessment
This issue has not been assessed yet.