coulomb/secrets-engine
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(recovery): prepare owner-bound offline continuity preflight
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1468b-63fa-7710-85dc-8f2e16b3ebfa
This commit is contained in:
tegwick 2026-10-17 01:03:36 +02:00
parent 535681052c
commit c59bbf568c
5 changed files with 248 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

38
docs/keycape-isolated-recovery-selector.md Normal file
View file

@ -0,0 +1,38 @@
# KeyCape original service recovery selector
Source-owner disposition, 2026-10-17, limited to secrets-engine's current consumer
contract. Current src/secrets_engine/service_auth.py fixes client/audience
secrets-engine-openbao, subject service:secrets-engine, tenant tenant:platform,
role secrets-engine and exact openbao:login scope. The NetKingdom producer binds
KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET; original KeyCape native evidence
uses openbao:admin as the denied-scope case. This selector matches the current
consumer source. This disposition is not native assent or a credential grant.
SECRETS-WP-0012 finished on historical attended custody/probe evidence and stays
finished. SECRETS-WP-0008-T06 retains functional steady-state adoption and scoped
backend entitlement. SECRETS-WP-0013 retains task-scoped backend execution. The
new SECRETS-WP-0015 covers only this original archive/isolated consumer preparation
and later accepted continuity proof; those existing gates are not duplicated.
The current consumer profile forbids a client-secret file and requires its
attended in-memory OpenBao source. That source depends on ordinary KeyCape OIDC
and OpenBao availability. The isolated issuer's native checker can consume its
original archive-delivered issuer binding without a provider login, but that does
not prove the secrets-engine consumer path works during an OpenBao/issuer outage.
Do not bypass the no-file/source contract, retrieve a live credential, redirect a
production consumer or invoke probe-openbao to fill this recovery gap. An exact
owner-reviewed outage-compatible proof/custody plan remains required.
Offline public preflight, after integration of reviewed source:
```sh
python3 tools/check-keycape-recovery-selector.py --selector docs/keycape-recovery-selector.json --source-sha256 sha256:c0ade429edf452ad17f05d690b7ebef091db7f1a42b5ac350f1e40955c8586c0
```
Use the exact hash in the owner packet, not a digest inferred at invocation from
an unreviewed file. The tool parses source constants with AST and never imports
the credential/backend module or calls the network. It requires all eight public
selector fields, exact source hash and unambiguous bounded JSON. Successful output
means source correspondence only. Original archived presence/secret binding,
actual TLS trust, native claim negatives and selected consumer continuity remain
separately evidenced. Missing/changed bindings refuse before any custody request.