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
{{ message }}
Repository navigation
feat(audit): retention with a signed checkpoint #327
The node audit log keeps one file per UTC day forever. Nothing trims it or caps its size. Since cryptos#323 stopped auditing status polling, the log grows only with real activity, but it still has no ceiling on the state partition.
Old files can't simply be deleted. VerifyChain starts at seq 1 from an empty-hash start, so removing the earliest files breaks verification. Retention needs a signed checkpoint: a node-signed record of the last removed seq and its entry hash. Verification then starts from that checkpoint.
Acceptance criteria
A retention setting in machine config: keep N days and/or a size cap, off by default.
Before any file is removed, the node writes a checkpoint entry signed with the node's key. It carries the last removed seq and entry hash, and the checkpoint itself is part of the chain.
VerifyAuditChain and cryptosctl audit verify start from the newest checkpoint and report its seq. A missing or forged checkpoint is reported as a broken chain.
audit list makes it clear that entries before the checkpoint were retired.
Tests come first: retention by age and by size, checkpoint verification, a forged checkpoint rejected, and verification across a checkpoint.
Docs describe retention and how to archive the log off-node before files are removed.
Notes
Found during the v0.1.0 matrix row 11 run. For v0.1.0, the docs caution added in cryptos#323 and the state-partition free space in cryptosctl status cover it. Related: #298, #323.
Activity