Correct remote layout and privacy docs for hashed snapshot keys (closes #67)
check / check (pull_request) Failing after 1s
check / check (pull_request) Failing after 1s
The remote layout and threat model in three documents described plaintext snapshot IDs as directory names and misattributed the observable backup time to those IDs. In fact `RemoteSnapshotKey` names each metadata directory (and the manifest `snapshot_id`) with a one-way double SHA-256 hash of the human ID, so hostname and snapshot name are not observable; the backup time is, via the plaintext manifest timestamp, an accepted design property (issue 81). Document the derivation once in `docs/REPOSTRUCTURE.md` with a worked example; README, ARCHITECTURE and DATAMODEL now show the hashed layout and link to it. Rewrite the privacy section to state what the unencrypted manifest really exposes. Fix two code comments that claimed the public bytes hide the timestamp. Docs and comments only; no behaviour change. Model: opus-4-8
This commit is contained in:
@@ -22,8 +22,9 @@ const remoteKeyPrefix = "vaultik|"
|
||||
//
|
||||
// - the "metadata/<remote-key>/..." subdirectory on the storage
|
||||
// backend so a directory listing of the bucket / file:// dest
|
||||
// doesn't reveal hostnames, configured snapshot names, or backup
|
||||
// timestamps;
|
||||
// doesn't reveal hostnames or configured snapshot names. (The
|
||||
// backup time is not hidden: the manifest.json.zst inside that
|
||||
// directory carries a plaintext RFC3339 timestamp.)
|
||||
// - the `snapshot_id` field of the unencrypted manifest.json.zst
|
||||
// for the same reason;
|
||||
// - any code path that needs to translate a known local snapshot ID
|
||||
|
||||
Reference in New Issue
Block a user