## Problem/Motivation Found in the second beta-readiness review of 1.x, and reproduced as a kernel test. The module promises that somebody with database write access and no signing secret is detected. That does not hold: 1. **A database writer can add a signing secret of their own.** The secret entities and their Keys are configuration, which lives in the database. The attack: - insert a Key holding bytes they choose, and a retired `audit_trail_secret` naming it; - rewrite an entry, and sign it again with those bytes under the new secret's id. A Strict full verification then reports the chain as intact. The real secret is never touched, and the site keeps logging normally. The same reaches every signature the module checks: entries, checkpoints, segments, acknowledgments and the outbox. 2. **The timestamp check trusts a CA certificate stored in the database.** The same writer can swap in a CA of their own and issue timestamps over the rewritten chain, or blank the certificate so the timestamp only reads as unchecked. Where the Key's bytes are kept does not matter: the attacker never needs the real secret. The same review found two smaller defects, both reproduced: 3. **A restore can be undone without trace.** The segment's lifecycle columns from before the restore still carry a genuine signature. Writing them back makes the old live-purge event match the segment again, and the restored rows can be deleted. A Strict full verification reported `5 entries intact`. The `segment_restored` event stays on the chain, but nothing compares it with the segment. 4. **Retention signs over a secret made unreadable.** A segment whose secret's Key could not be read was carried through compaction and every retention step unchecked, and the step then signed it under the live secret. Pointing a retired secret at a Key that does not exist is a configuration edit. With that, a row count changed by hand was folded into a consolidated segment; once the Key reference was put back, the chain verified with the forged count. Found in the audit loop on this issue's MR, reproduced. 5. **A forged acknowledgment is honoured under a secret that does not resolve.** Rows inside an acknowledged range are skipped by the walk, so one of them can be rewritten into an acknowledgment event covering any row below. Its signature was the only check left, and an event whose secret did not resolve was replayed unread. With pinning on, naming a listed secret whose Key was then pointed at other bytes or at nothing hid a tampered row: a Strict walk reported `9 entries intact` and authenticated. Found in a third review, reproduced. 6. **A row signed by an untrusted secret read as unchecked.** The entry page and a `Tolerant` walk took a secret `settings.php` refuses for one nobody could check. 7. **A full walk stamped in the future stopped cron's full walks.** A State value years ahead kept every tick incremental, and an incremental walk never reads below the checkpoint. 8. **A transient purge erased a detected tamper.** It cleared every bucket in the range without comparing them with their signed hash, so a bucket edited by hand, a break the walk reported, was cleared with the rest and the chain read clean. Found in a fourth review, reproduced. 9. **A throttle stamped in the future stopped retention and timestamping.** As for the full walk, a State value years ahead held back every retention stage, or every timestamp, on the chain for good. 10. **An unsigned segment row turned genuine outbox entries into "copies".** How far retention purged was read from any live-purged segment row, signed or not. 11. **Restore signed rows that were forged before archiving.** The archive file carried no row signature, and restore signed each row afresh, so a row rewritten and re-hashed before it was archived came back signed: a Strict walk went from broken to `9 entries intact`. Found in a fifth review, reproduced. 12. **Allowing a missing secret also allowed one no secret has.** With the waiver, a restore accepted a lifecycle secret nobody ever had, or one `settings.php` refuses, and then signed the stamps it carried, the purge mark among them, under the live secret. 13. **One tampered transient bucket made a whole segment unrestorable.** 14. **The rotation steps pinned a planted secret.** Once pinned, the lines offered still held every configured secret, a pending one planted as configuration included, and the documented rotation pasted them all. Found in a sixth review, reproduced. 15. **A staged write was chained twice past a broken segment.** Breaking the newest purged segment's signature for the length of a flush made the backlog read an older cut-off; after a clear, a copy needed no tampering at all. 16. **Restoring an imported archive onto a chain started again failed with the wrong cause**, a unique-key error blaming another chain. 17. **Every import left the segment index reading as altered.** The rebuild the status report then asked for reset the segment's archive columns, and it could no longer be restored nor imported again. 18. **An acknowledgment across a coverage bucket's edge stopped retention for good** on the rows around it. 19. **Finding uncovered rows grew with the segments**: one query per gap between segments, and two placeholders per segment above a stuck row, past the database's limit on a long-lived chain. 20. **A planted segment row hid a deletion from the purge.** The purge read the link the range's first row must have from whatever segment row ended just below it, signed or not: deleting the range's first rows and planting one naming their successor purged them without the mark. Found in a seventh review, reproduced. 21. **`--add` printed a planted duplicate's fingerprint.** A secret entity written as raw configuration with the new secret's id, created earlier, was the one the id resolved to. 22. **A break from before coverage escaped the archive and purge checks.** Coverage cuts its segments at a break, so the break lands on a segment's lower boundary, where its sealed anchor agrees with the first row. Found in an eighth review, reproduced. 23. **A restored import from another site could not be purged again.** Every later retention step checked its identity signature under a secret this site never had. 24. **A duplicated secret could not be deleted**, although the refusal said to delete it. 25. **Deleting a segment's last rows was laundered by its purge.** The range check never compared the last row with the hash the segment was sealed with; once purged, the row above links to that hash again. Found in a ninth review, reproduced. 26. **An acknowledged deletion read as broken after retention**, and **an acknowledgment across a deleted row stopped coverage for good**: coverage cut its segments at every break, the acknowledged ones included. 27. **A planted duplicate secret unlocked deleting the genuine one.** 28. **Compaction made an acknowledged break read as broken for good.** It folded the purged segment an acknowledgment is anchored on into a wider one. Found in a tenth review, reproduced. 29. **A planted acknowledgment index row stalled coverage**: retention steered around the index table's rows, which are ordinary data. 30. **A purge right after another one does not check its first link.** The row before the range was already purged, so its hash was reported as unknown and the link into the range was skipped. A row deleted there was purged over without the "purged while it did not verify" mark. The walk still reports the break afterwards. 31. **Rows lost at the end of a day read as broken after the first purge, for good.** Coverage cut the break between two segments, and the walk could not enter the second one, acknowledgment or not. Found in an eleventh review, reproduced. 32. **A restore rewrote an edited row's hash**, so its acknowledgment stopped holding and the next purge marked the range. 33. **Compaction read the acknowledgment index table.** Deleting one index row let it fold an acknowledged segment; planting one stopped compaction for good. 34. **A key found by trying random ones unlocked deleting a secret** whose own Key had been pointed elsewhere. 35. **A planted segment row steered the walk past a segment marked at purge**, and the chain read verified. Found in a twelfth review, reproduced. 36. **Coverage stopped for good** on rows below an acknowledgment above rows archived by hand, and on a chain with an acknowledgment wider than one cron run's buckets or rows. 37. **Overlapping acknowledgments logged a coverage failure on every run** about a sound chain. 38. **A write chained late from the outbox retired younger rows days early.** A segment was dated by its last row. 39. **A segment's dates came from row times nobody verified.** Rows dated back for one run were retired early under a clean verdict; a row dated ahead held a segment back forever; rows dated back under an acknowledgment were archived, purged and their file removed in one run. Found in reviews sixteen and seventeen, reproduced. 40. **A withdrawn acknowledgment came back for one purge.** Acknowledgment events outside a claimed range were replayed without their signature; and hiding a genuine withdrawal for the minutes a purge takes revived the acknowledgment, which excused a tampered row: it was purged unmarked into a signed archive, and the chain read clean once the event was back. Found in reviews eighteen to twenty-one, reproduced. 41. **A row rewritten only while the archive was written was purged unmarked.** The archive is signed over what the rows held at that moment; put back afterwards, the rows were sound again at the purge, which deleted them, and the only copy left was the forged file. Found in the audit loop on this issue's MR, reproduced. 42. **A row taken out of the archive, or written with a garbled signature, for that moment** was deleted with no copy at all, or turned a genuine row into a forged one on restore. Reproduced. 43. **An acknowledged row explained a row forged for the archive.** The purge named only the first row the archive and the chain held differently, so an acknowledgment ahead of it in the segment explained the purge, and a row rewritten for the archive further on went with it, unnamed. Reproduced. 44. **A row whose version was altered stopped its segment's purge for good.** The purge compared the archive line with the live row by its chain hash, which needs a version this release computes, so it threw on every run, after the operator had acknowledged the row. Reproduced. ## Proposed resolution Take the trust out of the database, optionally, through `settings.php`: ```php $settings['audit_trail_trusted_secrets'] = [ '4da5b88e' => '<64-character fingerprint>', ]; $settings['audit_trail_tsa_trusted_ca_certs'] = [ 'example_tsa' => '<SHA-256 of the CA certificate>', ]; ``` - A secret's fingerprint is the HMAC-SHA-256 its id is already cut from, in full. The id is four bytes and can be matched by trying random keys; the fingerprint cannot, and it reveals nothing about the secret. - Once pinned, a secret that is not listed, or whose Key holds other bytes, verifies nothing and signs nothing. It cannot be put in the signing role either; the refusal names the setting. - Once pinned, a timestamp whose provider is not listed, or whose certificate changed or was removed, fails instead of passing or reading as unchecked. - Without the settings nothing changes, and the status report warns. The lines to paste are shown: - on the secrets page, with a column saying whether each secret is trusted; - on the status report, while nothing is pinned; - by `drush audit_trail:secret-fingerprints`; - on the timestamp providers page, for the certificates. One small class reads both maps and builds the lines. A dedicated docs page explains pinning and rotating with pinned secrets. For the two smaller defects: - A `segment_restored` event is reported when the segment's live-purge pointer is older than it: a restore points it at itself, and a later purge moves it further on. - Compaction and every retention step refuse a segment whose secret will not resolve, whether no secret has the id or its Key cannot be read. Retention waits until the Key can be read again; the status report names it. Only an operator's explicit *allow missing secret* on restore or import passes it. - The hash of a purged row just before a range comes from the segment that purged it, its `anchor_after`, sealed at archive time. - An acknowledgment event whose secret does not resolve is not replayed: it excuses nothing, and the range it covered is reported again. - `settings.php` refusing a secret raises `SecretNotTrustedException`, and what it signed reads as forged at every depth that reads signatures: rows, lifecycle signatures and segment bridges. - A full walk stamped in the future is read as none, so the next tick walks in full. So is a retention or timestamp throttle stamped in the future. - A transient purge clears only buckets that still match their signed hash. A tampered one is left, so the walk goes on naming the row. - The backlog reads how far retention purged only from segments whose identity and lifecycle signatures hold. - The archive file carries each row's signature, and restore writes it back as it was. - The waiver passes a lifecycle signature only for a secret this site knows whose Key cannot be read. An import signs its segment's lifecycle under this site's signing secret, so a foreign lifecycle secret no longer occurs, and the import refuses a footer secret `settings.php` refuses. - A row whose transient context does not match its signed hash is restored as archived, named in the result and the messages, and reported by the walk. - Once pinned, the lines offered hold only trusted secrets and those named with `drush audit_trail:secret-fingerprints --add=<id>`; an unlisted pending secret is a warning saying it may be planted. - The backlog is held while any live-purged segment's signatures do not hold, and a staged write older than the chain's latest clear is a copy. - An import records its archive step on the chain (`segment_archived`), so the index agrees with it. - A restore into a chain started again since the archive (cleared, or a database rebuilt) is refused before anything is written, pointing to `drush audit_trail:archive-verify`, which checks the archive on its own. The docs no longer promise `--restore` there. - Coverage joins the buckets an acknowledgment spans. - Uncovered rows are found with one `NOT EXISTS`, and a gap whose segments' anchors join is not queried. - When a timestamp was taken is documented as unchecked, in the threat model and the TSA README. - Archive and live-purge check the range's first row against the segment's own `anchor_before`, which its identity signature covers, and every transition checks that signature first. Compaction uses the same check. `ChainRepository::getPredecessorHash()` is back to answering nothing across a purged range, and `hasEarlierRows()`, no longer used, is removed. - An id two secret entities carry resolves to nothing and is never offered; nor is a secret whose Key's bytes give another id. - An outbox entry left waiting longer than `live_purge_after` is documented as refused as a possible copy. - The sealed anchor is also held to what lies below the range: the chain's live row, or the identity-signed `anchor_after` of the segment below, or genesis. - A retention step passes an identity secret no entity here carries, on this site's lifecycle signature; compaction still refuses it. - A secret entity duplicating another's id can be deleted, through the API and the form, only while another entity's Key gives the id. - The range check also requires the range to end on the segment's `anchor_after`. - Coverage does not cut at a break an acknowledgment covers. - Compaction never folds a segment an acknowledgment reaches into. - Coverage steers by the acknowledgments the chain records (`AcknowledgmentRepositoryInterface::listRecordedRanges()`), not the index table. - A duplicate secret entity is compared by full fingerprint when its own Key may be the genuine one. - Restoring and purging again a segment whose acknowledgment's own event was purged is documented: acknowledge the range again. - Two limits are documented in the threat model: recording settings edited in the database, and the "no longer verifies" alert being decided from State. - Coverage starts an acknowledgment at the chain's row before its first, so a break left by rows lost at a bucket end stays inside one segment. An acknowledgment wider than one run is covered once its last row is due, and the bucket cap applies after joining. A range held short of an acknowledgment not yet due stops below every acknowledgment its end would cut. - The walk crosses a purged segment on an acknowledgment that starts on its first row, and only a signed segment starting exactly there. - The archive file's row lines carry the stored hash, and restore writes it back. - Compaction reads only the acknowledgments the chain records, and only when two segments could fold. - A duplicate of a secret whose own Key moved counts only on the pinned fingerprint. - A segment is dated by its newest row, and a fold by the newest of its run. A segment over a row dated after the clock is refused. The range check reports a row newer than its segment's date. - An acknowledgment signs the time of its range's newest row when it is recorded or updated, and acknowledged rows are dated by it. - The replay checks the signature of every acknowledgment event. - **The live-purge no longer decides whether an acknowledgment excuses a break.** It marks every broken range, and seals the acknowledgment that covered its breaks as their explanation: `verification_failed_at_purge` is 0, 1 for a break nothing acknowledged, or that acknowledgment's id. The walk honors a sealed explanation only if the chain's signed events before the purge show every acknowledgment the purge event names neither withdrawn nor narrowed off a broken row it covered. An explained purge then reads as explained for good, after the acknowledgment's own event has aged out too. - Import refusing an archive that holds a row edited before it was archived is documented; restore still brings such rows back. Tests (each fails when its check is removed): - A secret planted through the configuration, signing a rewritten head, reads as genuine unpinned and as broken pinned. It does not count as a registered secret either. - A pinned id with another fingerprint is refused. - An unlisted secret cannot be put in the signing role. - The status report warns unpinned, is OK pinned, and errors when the signing secret is not listed. - The offered lines, pasted, trust the secrets. - A pinned CA certificate still verifies a genuine timestamp. A replaced or removed one fails, not inconclusive. - A restore written back to the state before it is reported. - Compaction refuses a member whose secret was pointed at a missing Key, with its row count changed. - A forged acknowledgment under a listed secret whose Key is gone, or holds other bytes, hides nothing. - A row, and each segment signature, re-signed by an untrusted secret fails at Tolerant too. - A full walk stamped ten years ahead does not keep cron incremental; neither do retention and timestamp throttles. - A transient purge leaves a tampered bucket, and the walk still reports it. - An unsigned segment row claiming a purge into the future does not refuse a genuine staged entry. - A row forged before archiving is still broken once restored. - The waiver refuses a lifecycle secret no secret has. - A tampered transient bucket does not block the restore and is reported. - A secret appearing once pinned is not offered to paste. - A copy is not chained past a broken segment, nor after a clear. - An imported segment agrees with the chain. - A restore onto a chain started again is refused, naming archive-verify. - An acknowledgment across a day boundary is covered. - Finding uncovered rows over 30 interleaved segments takes a bounded number of queries and placeholders. - Deleting a segment's first rows marks its purge despite a planted segment row below it. - A duplicate secret id, or a Key giving another id, is never offered. - A row deleted before coverage marks its segment's purge. - A restored foreign import is purged again. - A duplicate of the signing secret can be deleted, and recording resumes; a planted one on other bytes does not unlock the genuine secret. - Deleting a segment's last row marks its purge. - An acknowledged hole, across it or on the break row, goes through coverage, archive and purge and still verifies; on a bucket's edge too, without a mark; and after compaction. - A planted acknowledgment index row does not stall coverage. - A row deleted right after a purged segment marks the next purge. - A break left by rows lost at a bucket end survives retention, whether both days are due together or the older one first, and when acknowledged late. - A restored edited row keeps its acknowledgment. - Compaction keeps an acknowledged segment whose index row is gone; a planted index row stops no compaction. - A key found by trying random ones does not unlock a secret moved off its Key. - A planted segment row cannot skip a segment marked at purge. - An acknowledgment above rows archived by hand, wider than one run or one scan, or overlapping another, stops no coverage and logs no failure. - Rows after a late write keep their windows; a fold keeps the newest date. - A segment over a row dated ahead is refused; rows dated back while it was declared mark the purge; acknowledged rows dated back do not date their segment; an acknowledged row dated ahead does not block its range. - An acknowledgment signs its newest row time on record and update; an edited acknowledgment event is not read. - A withdrawal hidden while a range is purged (deleted, garbled, renamed, or deleted and relinked) and a hidden narrowing do not explain the purge; a later break, and a second acknowledged one, leave the explanation in place; a hidden withdrawal is caught behind a newer acknowledgment of another break too. - A row rewritten, taken out or with its signature garbled only while the archive is written marks the purge; every row the archive holds otherwise is named, whatever acknowledgment comes before it; a row of an unknown version does not hold the purge. ## Remaining tasks None. ## User interface changes - A *Trusted in settings.php* column and the lines to paste on the secrets page. - A *CA trusted in settings.php* column and the lines to paste on the timestamp providers page. - A *trusted secrets* entry on the status report. ## API changes - `SecretRepositoryInterface::getFingerprint()`, `listFingerprints()`, `isSecretTrusted()`. - `SecretNotTrustedException`. - `AcknowledgmentRepositoryInterface::listRecordedRanges()`, with the signed `newest_created`, and `readStateBefore()`. - `AuditTrailVerifier::listBreaksInRange()`. - `ChainRepository::getNewestCreatedInRange()`. - `SegmentSignature::PURGE_MARK_UNEXPLAINED`. - `AuditTrailSecret::computeFingerprintFromBytes()`. - `TrustedSecretSettings`, `TrustedCaSettings`, `PinnedFingerprints`. - `drush audit_trail:secret-fingerprints`. ## Data model changes - The archive file's row lines carry the row's `hash` and `hmac`. Archive files written before this change cannot be restored; there is no compatibility path before 1.0. - `audit_trail_segment.verification_failed_at_purge` becomes a big unsigned integer: 0, 1, or the id of the acknowledgment sealed as the explanation. - Acknowledgment events carry `newest_created`. - A segment's `to_created` is its newest row's time. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)