Chronicle.
Copy Markdown
Reports the signing keys required to verify a named audit store.
Key material is never read back or returned. The result contains only key
identifiers that are present in the ledger and the identifier configured for
new writes. This module is reached by operators and by mix tasks, so it is
assumed its output will end up in a terminal, a log, or a screenshot.
Summary
Functions
Low-level operation that verifies the store, then appends a transition signed by the old key and proven with the new key.
Functions
@spec generate() :: String.t()
@spec rotate(atom(), String.t(), Chronicle.Key.source()) :: {:ok, map()} | {:error, Chronicle.Error.t()}
Low-level operation that verifies the store, then appends a transition signed by the old key and proven with the new key.
This function cannot coordinate application nodes. The caller must drain
writers and apply the returned epoch boundary and both keys across all nodes:
the old key is valid through transition_sequence; the new key begins at
activates_at_sequence. Prefer the non-mutating
mix chronicle.keys.rotate planning workflow first.
The whole store is verified before anything is written, and that ordering is not politeness. Rotation appends a transition entry signed by the outgoing key, so performing one over a chain that is already broken would anchor a fresh epoch onto corrupt history and lend it the new key's authority. If the ledger cannot be verified, there is nothing here worth rotating onto.
A key id is refused if it already appears in the ledger. Entries name their signer by id, so reusing one makes two different keys indistinguishable in the historical record — and a verifier reading that record has no way to tell which of them it should be holding.
@spec status(atom()) :: {:ok, map()} | {:error, Chronicle.Error.t()}