Record archive recovery lifecycle and validate receipt provenance
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06ecb-456a-71c2-b41e-0755d336e883
This commit is contained in:
parent
445f1361dc
commit
a867ec269a
9 changed files with 203 additions and 11 deletions
|
|
@ -115,3 +115,17 @@ Update pins only after reviewing replacement evidence. Native database recovery
|
|||
does not attest full application or essentials recovery. Legacy archive receipts
|
||||
without completion timestamps remain manual evidence; no timestamp is inferred
|
||||
from file modification time. Automatic cadence and alert delivery remain pending.
|
||||
|
||||
New archive runs record UTC `started_at` and terminal `finished_at` in transfer,
|
||||
decryption and isolated restore receipts, including failures. A timestamp alone
|
||||
is not success: consumers must validate status, provider/profile, hashes and
|
||||
cleanup. Restore completion is recorded after scratch cleanup, and cleanup
|
||||
failure sets status to `failed`. Decryption and restore also record SHA-256 of
|
||||
the exact input receipt bytes as `transfer_receipt_sha256`.
|
||||
|
||||
Decryption now retains `platform.forgejo-primary-decryption.v1` and its own
|
||||
operation times; older decryption receipts used the transfer schema through an
|
||||
overwrite bug. The restore tool explicitly accepts both forms, with verified
|
||||
hash/decryption flags. Existing historical receipts are unchanged. These producer
|
||||
fixes enable future dated archive evidence; automatic archive adapters, fresh
|
||||
end-to-end receipts and recurring execution are still pending.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue