fix(bep): bound the secret-tool output drain after exit · gominimal/minimal@7da0429

CONDITIONS

Governs (arch 15b603e6, found by search because the checkout has no arch-map.md): Gatehouse §6.10 line 837 (hardware custody is a SHOULD where it offers it, TPM 2.0 on Linux). §6.10 line 832 (the sealing key is immutable except by re-enrollment). Design principle 7, architecture.md line 337 (safe by default). The repo spec 24-spec-box-egress-proxy BEP-088 to BEP-090 records the owner's Secret Service fallback.

Baseline. This re-reviews 7da04290 against the CONDITIONS on e6f78571 (this PR). The ledger cuts the earlier rulings at 400 characters, so I could not read their conditions. I ruled the whole head on pr.diff and read since.diff first. The revise commits (1921d6e, 2f9e52e, 7da0429) each close a fail-closed gap: a broken-pipe write, an unanswered prompt, a silent lock, and now a pipe that an autolaunched D-Bus holds open.

Ruling. Placement conforms. secret_service.rs is in bep beside signin.rs, behind cfg(target_os = "linux"). The refusals print the pinned wording, keep the keys and name no replacement. The store logs role, fingerprint and store=secret-service on each load and each generation. The new drain fixes the hang, but it fails open. When the grace ends before the reader thread reads the output, run returns empty output as a success, and lookup reads it as an empty slot. A held key then reads as missing. The start then names --replace-key, or on a host with no published identity it generates over the held item. That breaks line 832 and principle 7. C1 makes an incomplete drain a refusal, and makes exit 0 with blank stdout unreadable, not empty.

Departure from precedent. None that I can see. SecretServiceKey::exportable() returns false for a key whose private half Secret Service lets out, and HeldKey::exportable is documented as whether the store lets the private half out. This was the same on every earlier head, and no revise commit changed it, so I take it that the earlier rulings accepted it under line 837's where it offers it. I do not condition it. BEP-090 owns the honest report. If a person wants custody to carry a store-level exception in place of the flag, that is a question for the BEP-088 task.

Not checked. I could not open elliptic-curve 0.14 offline, so I did not confirm whether SecretKey::from_slice accepts a short slice. It does not change C1. I did not build or run the tests, because the rules forbid it. No findings.json was staged.

Conditions

C1: crates/bep/src/secret_service.rs: Drain::collect returns the bytes and whether the pipe reached its end by the deadline. SecretService::run never returns Ok(out) when a pipe did not reach its end. It returns failure(role, &out) when the stderr read so far is not blank, and otherwise KeyError::Store with a detail that says an output pipe of secret-tool stayed open. Then lookup and listed cannot read an output that is not complete as an empty slot (Ok(None) / Ok(false)). In lookup, a secret-tool lookup that exits 0 with blank stdout (line 228) returns unreadable(role), not Ok(None): only exit 1 with blank stderr and no listed item is an empty slot, as commit 2f9e52e states. Add a test, a_lookup_whose_pipe_stays_open_is_not_an_empty_slot: a fake secret-tool that starts sleep 30 & and exits 0 with no output, or exits 1 with no message, makes lookup return Err, not Ok(None).

_{Ruled at 7da0429 against gominimal/arch@15b603e6afb8 by claude-opus-5-5; arch_rulings 1202, job 30b8064b-9dd7-41a7-bf1e-6133cde2ac49.}

Navigation Menu

Repository navigation

CONDITIONS

Re-running checks...