Finding
The installation identity is documented as the signer that proves tamper-log provenance, but production log records contain no installation key identifier or signature. The only exposed identity command generates a new identity on every invocation, so it cannot identify an installation over time.
Evidence
crates/kryphos/src/key.rs:163-167 says InstallationIdentity is used to sign tamper-log entries and prove they originated from a specific installation; lines 226-231 provide sign_entry.
The on-disk LogEntry at crates/koinon/src/tamper_log.rs:202-245 contains only sequence, timestamp, event payload, and a keyed BLAKE3 chain hash. crates/kryphos/src/storage.rs:497-505 opens the log and appends a mutation without an identity or signature. A repository-wide production search finds no caller of sign_entry.
Meanwhile, crates/akroasis/src/vault/mod.rs:342-358 implements vault identity by calling InstallationIdentity::generate() each time and printing that fresh public key. PR #38 notes the command's ephemeral behavior, but no issue owns the absent production provenance layer.
Why this matters
The current chain can show integrity relative to the passphrase-derived chain key, but it cannot establish that records came from one stable installation as the public contract claims. Operators and future federation peers have no durable identity against which to verify provenance, and the command presented as installation identity returns a different answer on every run.
Desired correction
Create one durable installation identity at initialization, protect/seal its signing key, and bind a stable key identifier plus a domain-separated signature to each record or authenticated log tip. Expose public verification that does not require the vault secret, define rotation/recovery semantics, and make vault identity read the persisted identity.
Done when identities survive restarts and repeated CLI invocations, production appends are signed, verification fails after signature/key-id substitution, and migration behavior for unsigned logs is explicit.
Finding
The installation identity is documented as the signer that proves tamper-log provenance, but production log records contain no installation key identifier or signature. The only exposed identity command generates a new identity on every invocation, so it cannot identify an installation over time.
Evidence
crates/kryphos/src/key.rs:163-167saysInstallationIdentityis used to sign tamper-log entries and prove they originated from a specific installation; lines 226-231 providesign_entry.The on-disk
LogEntryatcrates/koinon/src/tamper_log.rs:202-245contains only sequence, timestamp, event payload, and a keyed BLAKE3 chain hash.crates/kryphos/src/storage.rs:497-505opens the log and appends a mutation without an identity or signature. A repository-wide production search finds no caller ofsign_entry.Meanwhile,
crates/akroasis/src/vault/mod.rs:342-358implementsvault identityby callingInstallationIdentity::generate()each time and printing that fresh public key. PR #38 notes the command's ephemeral behavior, but no issue owns the absent production provenance layer.Why this matters
The current chain can show integrity relative to the passphrase-derived chain key, but it cannot establish that records came from one stable installation as the public contract claims. Operators and future federation peers have no durable identity against which to verify provenance, and the command presented as installation identity returns a different answer on every run.
Desired correction
Create one durable installation identity at initialization, protect/seal its signing key, and bind a stable key identifier plus a domain-separated signature to each record or authenticated log tip. Expose public verification that does not require the vault secret, define rotation/recovery semantics, and make
vault identityread the persisted identity.Done when identities survive restarts and repeated CLI invocations, production appends are signed, verification fails after signature/key-id substitution, and migration behavior for unsigned logs is explicit.