You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
deploy/community/backup.sh writes database.dump, app-data.tar.gz, privacy-data.tar.gz, METADATA and SHA256SUMS into a directory with mode 700. Nothing is encrypted.
The documentation is honest about it — BACKUP-RESTORE.md:37 says
"Immediately copy the completed directory to separately encrypted storage" —
so this is a stated design decision, not a hidden gap.
The problem is what that decision leans on. The archive contains participant
interview content, uploaded documents and the privacy dataset, and it sits
unencrypted on the host until a human performs a separate step that nothing
checks, reminds, or verifies. "Immediately" is doing a lot of work in a
procedure that runs on a schedule.
There is also a concrete inconsistency: #29 lists as an acceptance criterion
"Produce an encrypted backup with a manifest and checksums, then verify it
before restore." That is not what the script does today.
What to decide
Should backup.sh encrypt at creation — a --recovery-password or a
recipient key — so the artifact is never in the clear on disk?
Either answer is defensible. What is not defensible is the current state, where
one document assumes a property another document says the operator must supply.
If encryption is added
restore.sh has to stay usable without the key for the parts that do not need
it, or fail with a message naming what is missing
Problem
deploy/community/backup.shwritesdatabase.dump,app-data.tar.gz,privacy-data.tar.gz,METADATAandSHA256SUMSinto a directory with mode700. Nothing is encrypted.The documentation is honest about it —
BACKUP-RESTORE.md:37says"Immediately copy the completed directory to separately encrypted storage" —
so this is a stated design decision, not a hidden gap.
The problem is what that decision leans on. The archive contains participant
interview content, uploaded documents and the privacy dataset, and it sits
unencrypted on the host until a human performs a separate step that nothing
checks, reminds, or verifies. "Immediately" is doing a lot of work in a
procedure that runs on a schedule.
There is also a concrete inconsistency: #29 lists as an acceptance criterion
"Produce an encrypted backup with a manifest and checksums, then verify it
before restore." That is not what the script does today.
What to decide
backup.shencrypt at creation — a--recovery-passwordor arecipient key — so the artifact is never in the clear on disk?
needs to be somewhere harder to miss than one line of a runbook.
Either answer is defensible. What is not defensible is the current state, where
one document assumes a property another document says the operator must supply.
If encryption is added
restore.shhas to stay usable without the key for the parts that do not needit, or fail with a message naming what is missing
test(self-host): prove install, upgrade, backup, restore, and erasure replay #29 lists exactly this case
backup directory
Acceptance criteria
#29andBACKUP-RESTORE.mdagree with the implementation afterwards