Record archive recovery lifecycle and validate receipt provenance
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06ecb-456a-71c2-b41e-0755d336e883
This commit is contained in:
codex 2026-09-06 14:53:15 +02:00
parent 445f1361dc
commit a867ec269a
9 changed files with 203 additions and 11 deletions

View file

@ -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.