## Problem/Motivation Found in the seventh release audit of 1.x at `945ecd3`. This audit attacked every place the module computes a signature over data it reads back from the database, as somebody with database write access and no signing secret. ### Security 1. **The outbox signs whatever is put in it.** A write made inside a transaction waits in `audit_trail_outbox` and is chained, and signed, by the flush. The staged row was protected by `content_hash`, a plain SHA-256 that anyone can compute. A row added to the table by hand, with its digest computed, was chained by cron's backlog flush and signed with the real secret: a Strict full verification then reports `Chain "webdav" verified: 2 entries intact.` for an entry the module never recorded. 2. **Rebuilding the segment index signs unauthenticated events.** `SegmentIndex::reindexChain()` replays the segment lifecycle events from the chain and signs the segments they describe. It read the events' content without checking their own signature, and took the lifecycle secret id from the event row itself. An event edited to widen a segment's range came back as a segment the module had signed. The status report recommends the rebuild whenever the index disagrees with the chain. 3. **A genuine staged row could be chained more than once** (found while auditing the fix for 1). A signature proves the module staged a row, not that it was staged once. A copy of a genuine row, made while it waits or after it is chained, carries the same signature: one entry was chained three times and the chain still verified. The same happened, without any attacker, when a request chained its row and ended before clearing it from the outbox. ## Proposed resolution 1. A staged row carries an HMAC under the signing secret (`content_hmac`) and the id of that secret (`secret_id`). The flush refuses a row whose HMAC does not verify. With no signing secret, nothing is staged, and the entry is reported as an immediate write with no secret is. The waiting rows count as a use of their secret, so it cannot be deleted under them. 2. The rebuild replays only events whose own signature holds (`ChainPayload::hasValidSignature()`), and names the events it left out. 3. Cron's backlog refuses a staged row the chain already holds (one lookup through the index on `created`) and a second row carrying the same signature in one batch. The write path is unchanged. Tests: - A row added to the outbox with a plain digest is not chained. - An entry with no secret to sign it is not staged, and is reported. - A segment creation event edited to widen its range is not signed back into the index, and is named. - A genuine staged row copied while it waits and again after it is chained is chained once. Performance: staging 2,000 writes in a transaction takes 65 ms instead of 60 ms (about 2.6 µs more per write, the HMAC itself). Resolving the secret on every write cost 15 µs and is done once per request instead. ## Remaining tasks None. ## User interface changes - `drush audit_trail:reindex-segments` names lifecycle events whose signature does not hold. - The secret delete refusal also names entries waiting to be chained. ## API changes - `PendingWrite::getContentHash()` is replaced by `computeContentHmac()`, and `toOutboxRow()` takes the secret id and the secret. - `OutboxPendingWriteBuffer` takes the secret repository. - `SegmentIndex::reindexChain()` returns `unauthenticated`. ## Data model changes `audit_trail_outbox.content_hash` is replaced by `content_hmac`, and the table gains `secret_id`. No update hook before 1.0: an existing site recreates the table, which is empty between requests. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)