session-history/ohm/0026/SESSION-0026.7-TRANSCRIPT-2026-05-28T13-46--2026-05-28T13-54.md

SESSION-0026.7 — Secret-byte sweep of the OHM session-history corpus

Parent: SESSION-0026.0-TRANSCRIPT-2026-05-28T13-46--INPROGRESS.md Subsession of OHM security-audit driver session 0026. Role: READ-ONLY assurance pass. Mission: sweep every published session transcript (plus the local working transcripts that get published) for any leaked SECRET BYTE — the §3-invariant-1 conversation-layer corollary.

Pre-state

Two scan surfaces:

1. PUBLISHED corpus — cloned read-only to /tmp/ohm-hist-scan-0026 from ssh://git@git.wiggleverse.org:2222/wiggleverse/ohm-session-history.git (clone exit 0; reachable).
2. LOCAL working transcripts at /Users/benstull/git/ohm-infra/SESSION-*.md.

File counts:

• Published: 29 transcript .md files (sessions 0001–0027, including the .1/.2/.3 subsession files), plus README.md. = 30 .md total.
• Local: 40 SESSION-*.md (includes INPROGRESS placeholders, SESSION-PROTOCOL.md, SESSION-L). Superset of published.

ABSOLUTE RULE held throughout: never reproduce a suspected secret value; report only pattern-name + location + masked form. No secret bytes were written here or in the report.

Turn-by-turn arc

1. Cloned the published repo (exit 0) and listed both surfaces. Counted files.

2. High-confidence shape sweep (grep -rniE, both surfaces, .git excluded):

   • Provider prefixes: sk-ant-, sk-… (OpenAI), AIza… (Google), ghp_/gho_/ghs_, glpat- → 0 hits.
   • PEM BEGIN … PRIVATE KEY → 0 hits.
   • GCP SA JSON ("private_key", "private_key_id", "type":"service_account") → 0 hits.
   • JWT eyJ….eyJ… → 0 hits.

3. Named-secret-var = value sweep (SECRET_KEY, GITEA_BOT_TOKEN, OAUTH_CLIENT_SECRET, GITEA_WEBHOOK_SECRET, etc. followed by =/: and a 6+ char value), plus a generic *_TOKEN/_SECRET/_PASSWORD/_KEY = value sweep. Hits were all adjudicated:

   • SESSION-0002 lines 950/961/967/971/974/1111 — placeholders: FILL_FROM_PASSWORD_MANAGER, FILL_FROM_OPENSSL_OUTPUT_ABOVE, and a literal openssl rand -hex 32 gesture, and a doc example GITEA_BOT_TOKEN=abc123.... Not real values. CLEAN.
   • SESSION-0008 line 316 — a shell grep '^OAUTH_CLIENT_SECRET=' command line, no value. CLEAN.
   • SESSION-0008 lines 684/685 — the CRLF-bug writeup showing OAUTH_CLIENT_SECRET=" gto_oge…\r" and SECRET_KEY="2e05383a849…\r". Opened lines 665–709. Both values are deliberately truncated with an ellipsis (…): only a ~3-char prefix of the gitea token and ~11 hex chars of the 64-char SECRET_KEY are shown, as illustration of the trailing-\r taint. The remaining bytes are NOT present. Verified gto_oge appears at lines 70/291/684/689 and is the same truncated 3-char suffix every time — never full length. CLEAN (truncated, sub-threshold).
   • SESSION-0001 line 984 — GITEA_SIGNING_KEY="7C9E…1592E2" (40-hex). Opened lines 972–993: it's inside /tmp/gitea-install.sh, used with gnupg/dirmngr to verify the downloaded Gitea release signature. This is the public GPG key fingerprint Gitea publishes. Public by definition. CLEAN.

4. High-entropy string sweep (standalone 48+ char base64/hex blobs in published corpus). Two non-trivial strings, both adjudicated:

   • 64-hex 15783e…574d (SESSION-0006 line 503) — explicitly labeled overlay snapshot sha256:…. A content hash of the (non-secret) overlay config. CLEAN.
   • AAAAC3NzaC1lZDI1NTE5… (SESSION-0001 line 683) — the standard ssh-ed25519 public-key wire-format prefix. Public key, not a private key. CLEAN. (Consistent with the PEM sweep finding zero BEGIN OPENSSH PRIVATE KEY blocks.)

5. Final confirmation sweeps:

   • bcrypt $2[aby]$NN$ → 0 hits.
   • password/passwd/pass/pwd = value (excluding prose, placeholders, --password flags, "password manager") → 0 hits.
   • README.md → only prose about the no-secret-bytes policy. CLEAN.
   • PRIVATE KEY / BEGIN OPENSSH / BEGIN RSA / BEGIN EC → all matches are prose discussing private keys (e.g. "client unlocking that private key", "No private key material … nothing sensitive", and a grep-pattern example inside a transcript). No actual key blocks. CLEAN.

Cut state — VERDICT: CLEAN

Zero secret bytes leaked across the entire corpus.

• 29 published transcript .md files scanned (+README).
• 40 local SESSION-*.md files scanned (published superset).
• The only "value-shaped" hits were all expected/safe: placeholders, a public GPG fingerprint, a public ssh-ed25519 key, a sha256 overlay snapshot hash, doc examples, and two deliberately-ellipsis-truncated illustration values in the CRLF-bug writeup (sub-threshold, remainder never present). No secret REFERENCES were mistaken for bytes; no references were flagged as leaks.

Driver needs to know

• Corpus is CLEAN. No remediation needed. The §3-invariant-1 conversation-layer corollary is holding in practice across all published sessions to date.
• One thing worth a glance (NOT a leak): SESSION-0008's CRLF-bug narrative quotes truncated …-elided forms of OAUTH_CLIENT_SECRET and SECRET_KEY. They are safely below any useful threshold, but if the team wants zero value-fragments at all, those two could be masked to pattern-name only. Optional, low priority.
• Published repo was reachable and freshly cloned; no "could not reach" caveat applies.