keep-cli: hardening & test-coverage backlog (9 items)

[kwsantiago]

Hardening and test-coverage findings in keep-cli.

Read this before picking anything up. The original list was produced by an automated pass whose header claimed each entry was verified still open. A manual pass on 2026-07-30 read the code for all nine and that claim did not hold: two were already fixed, two overstated a gap that had been partly closed, and one asked for the wrong property entirely.

Entries here name where the code looks wrong. They are not instructions. Read the code before acting on one, and if it does not say what the entry says, correct the entry.

Open

• Software and hardware DKG scaffolding duplicated — Two large command functions with duplicated relay setup, round-1 publish, fetch loops, timeouts and encryption. No shared transport helper extracted. Also listed on the keep-frost-net backlog; do them together.
• Wallet spend holds the share resident for the coordination wait — cmd_wallet_spend unlocks the vault and keeps the FROST and OPRF share material resident for the whole wait, with no re-authentication at finalize. A fifteen-minute cap bounds the window; the resident-key exposure inside it is unchanged.
• Software DKG has no echo round over the full round-1 set — Narrowed. An equivocation check exists and is deliberately extracted so the decision is unit-testable without relay I/O, and peers wait for group-key confirmations. What is still missing is an echo round hashing the complete round-1 set, and a comment in the fetch loop still records the single-relay exposure.
• OPRF serve plumbing partly untested — Narrowed. load_oprf_key_share has three tests covering a missing file, malformed bytes and a valid round trip. The share-file and dealer flags and the seal handler remain uncovered.
• Duress state directory has no tamper-evident anchor — Narrowed. The premise that an absent state file silently unfreezes no longer holds: a read-side check refuses to trust the state directory when it is group- or world-writable without the sticky bit, shared with the boot-time probe so the two cannot drift. What the entry additionally asked for, an anchor making deletion detectable rather than merely hard, is a separate and larger change.

Removed as already fixed

The signature share is no longer printed unconditionally; it goes through a debug-level log, with a comment recording that publication in the signature event is its intended egress. write_secret_file has tests covering empty and binary payloads, stale-temp cleanup from a crashed run, and replacing a symlinked destination without writing through it. Session id generation now routes through the core entropy helper, which applies the health check that fails closed; the framing in the original entry was wrong, since the previous source was already a CSPRNG and what it skipped was the health check rather than randomness quality.

Removed as wrong

Nonce store not encrypted at rest. The file holds no secrets. Each record is a commitment, timestamps, a used flag and a session id. A FROST commitment is public by construction: it is broadcast to the coordinator, and the secret nonce it commits to never leaves the signing device. Encrypting a file of public commitments buys no confidentiality and adds key management for nothing.

The property that would matter is integrity, since the used flag is a reuse guard and reuse of a FROST nonce leaks the share. Except the flag is not doing that job: the function that marks a nonce used and the one that queries it are both dead code with no callers. Nothing in the CLI ever sets it, so the used count an operator sees is always zero and no host-side reuse check happens. Reuse prevention rests entirely on the device, which tracks consumed session ids and writes nonce checkpoints, and that is the right place for it. The real work is either removing the unused tracking so the store is honestly a record of what was generated, or wiring it up so the flag is set and consulted, at which point integrity protection becomes worth discussing.

[kwsantiago]

Re-verified all nine items against current main by reading the code rather than trusting the checklist. Roughly half no longer describe the tree, so the list overstates what is left.

No longer present

• Signature share logged to console. The share is no longer printed unconditionally. It goes through debug! in the hardware signing path, with a comment recording that the event publication below is its intended egress. Fixed.
• write_secret_file has no tests. There are now tests covering empty and binary payloads, stale-temp cleanup from a crashed run, and replacing a symlinked destination without writing through it. Two of the three properties the item names are directly covered.

Overtaken by later work, needs rewording rather than closing

• Duress state-file deletion silently unfreezes without detection. The premise no longer holds: there is a read-side fail-closed check that refuses to trust the state directory when it is group- or world-writable without the sticky bit, shared with the boot-time probe so the two cannot drift. What the item asks for beyond that is a tamper-evident anchor, which is a different and larger change. The directory-permission half is done.
• No tests for OPRF holder runtime serve plumbing. load_oprf_key_share now has three tests, covering a missing file, malformed bytes, and a valid round trip. The share-file and dealer flags and the seal handler remain uncovered, so the item should be narrowed to those.
• Software DKG trusts an untrusted relay. There is now an equivocation check, deliberately extracted so the decision is unit-testable without relay I/O, plus a peer group-key confirmation wait. The full echo round hashing the complete round1 set is still absent, and a comment in the fetch loop still records the single-relay exposure, so the core of the item stands but the "no consistency check at all" framing does not.

Confirmed still present

• Software and hardware DKG scaffolding remain two separate large functions; no shared transport helper was extracted.
• The nonce store still serializes to plaintext JSON with no encryption at rest.
• Wallet spend still holds the share resident for the coordination wait; the 15-minute cap is the only mitigation, which the item already acknowledges.
• Session ID generation still uses a thread RNG rather than the core entropy helper. Worth noting the reason this matters is not weak randomness, since that RNG is a CSPRNG, but that it bypasses the entropy health check that the rest of the codebase routes through and that fails closed. A fix is prepared.

[kwsantiago]

The nonce store entry asks for encryption at rest. That targets the wrong property, and verifying it turned up something more worth knowing.

The file holds no secrets. Each record is a commitment, a creation timestamp, a used flag, an optional used timestamp, and an optional session id. A FROST commitment is public by construction: it is broadcast to the coordinator, and the secret nonce it commits to never leaves the signing device. Encrypting a file of public commitments buys no confidentiality, so the item as written would add a key-management burden for nothing.

The property that does matter here is integrity, not confidentiality, because the used flag is the reuse guard and reuse of a FROST nonce leaks the share. An attacker who can flip that flag back is far more dangerous than one who can read the file.

Except the flag is not doing that job today. The two functions that would enforce it, the one that marks a nonce used and the one that queries it, are both dead code with no callers anywhere. The only operations actually used are opening the store, appending a commitment, and reading counts for display. Nothing in the CLI ever sets the flag, so the used count an operator sees is always zero and no host-side reuse check happens at any point.

Reuse prevention today rests entirely on the device, which tracks consumed session ids and writes nonce checkpoints. That is the right place for it. The gap is that the host store looks like a second line of defense and is not one, and the statistics it prints imply tracking that does not occur.

So this item should be reworded away from encryption. The useful work is either removing the unused tracking so the store is honestly just a record of what was generated, or wiring it up so the flag is set and consulted, at which point integrity protection for the file becomes worth discussing. Both are larger decisions than the entry implies, and picking one needs a view on whether the experimental precommit path is being kept.