New command borg history --manifest
will list out all segment
entries that are PUTs of an all-zeroes key, along with their decrypted
values.
If a repo has been maintained strictly in an append-only manner, and no deletions attempted by an adversary with append-only access, then this will provide a listing of all archives that were ever created. If such an adversary attempts to delete an archive, they'll have to add a new manifest which omits an archive -- and that can be detected by comparing it to older, shadowed manifests.
The invariant can be maintained across authorized deletions if the rightful owner fully compacts after deletions. Process below.
- Verify integrity of recent backups via spot-checks or other situation-specific criteria
- Perform a
borg check
- With lock:
- Read the local list of known-deleted archive IDs (initially empty)
- Run the new
borg history --manifest
command - From the history output, confirm that the archive list only ever
grows from one version of the manifest to the next, or that any
dropped archive IDs are in the known-deleted list
- If there are any unexpected archive removals, log and and exit with an error -- this may be the sign of an attack
- Log this history locally for reference (since it will be lost)
- Choose which archives to prune
- Add them to the known-deleted list
- Perform the
borg delete
action - Perform
borg compact
with 0% threshold so that all DELETEs are compacted
Afterwards, there will only be a single manifest in the history, thanks to the compaction.
Ideas for a the other things a plain
borg history
without the--manifest
limitation should:PUT
s, report anyPUT
for a chunk ID other than 0 that has beenPUT
before as an issueborg recreate
doing recompression (which makes little sense on an append-only repo in the first place and would rather be done with apend-only dropped after running this command as part of auditing the repo before doing so)append-only
mode disabled, thus in any practical use-case after this command has been used to audit the repository before disablingappend-only
mode and can be expected to be completed/any results of it being aborted to be cleaned up/repaired before continuing actual use of the repository that ultimately may lead to another audit of its history.PUT
zeroad out chunks before then putting tampered ones to masquerade the tampering as a repair, and the presence of both repaired and unrepaired (lastPUT
zeroad) is still noteworthy to point out in the repository history when legitimate:borg check --repair
PUT
ing zeroed chunks, which due to conflicting withappend-only
mode would just like above operation only be done after audit & disabling ofappend-only
mode.borg create
after aborg check --repair
PUT
ing chunks that heal zeroed ones. This may happen lateron, and if the chunks to heal are not taken from other backups through the secure mangemant/temporary system used for the audit, but from the potentially hacked client, it actually should happen withappend-only
mode enabled.borg history
pointinng out any files repaired the latter way would then be used in the next audit&repair cycle to specifically audit the contents (checksums/hashes) against records of those at time of backup before letting the repair finally heal them.DELETE
s other than chunk ID 0 (handled by the manifests part) or those referring to an archive that is a checkpointborg rename
(I'd assume those to show asDELETE
(s) of the meta data of the old archive andPUT
(s) of meta data for a new archive differing only in the encoded name)