Secrets audit — current tree and full git history, both repos

done priority 1 estimate M

workspace-dashboard/001 · created 2026-08-05 · updated 2026-08-04

Findings

See ../001-secrets-audit-findings.md for the full report. Result: clean — no secrets found in either repo’s working tree or full git history. One caveat the audit can’t resolve: the password that triggered this audit was reportedly typed into a past task-runner session / chat, which lives outside any repo this audit can search — so “clean in git” isn’t the same claim as “never exposed.”

Reviewed by Kris 2026-08-04, and the rotation call was made: rotate anyway (out of caution over the transcript-exposure caveat). New signing key created: .secrets/lor2026.keystore, alias lor, password in .secrets/lor2026.keystore.password — present both locally and in the AI Task Runner container’s .secrets/. The old lor.keystore is superseded (kept only for updating already-installed lor-elementals APKs). Full resolution note at the bottom of the findings file. The visibility question was decided the same day: all lor repos stay private — see ../questions/001-repo-visibility.md.

What to do

Exactly the scope already specified in overview.md’s “FIRST TASK” section — carried across verbatim here, not re-derived:

Search the current working tree of both lor-workspace and land-of-lor for: any .keystore/.jks file, any plaintext password/credential string, any API key or token pattern.
Search the full git history of both repos (not just HEAD) for the same — deleting a file today does not remove it from history. Walk history properly (git log -p, or a real secrets-scanning tool against full history), in both repos.
Report exactly which repo(s) and which commit(s) anything is found in.

Definition of done

A findings report (clean, or precise: repo + commit + what). If anything is found: state plainly that a leaked Android signing key lets a third party sign malicious packages users’ devices will accept as legitimate updates — this is not a routine secret leak. Do not rotate anything or rewrite any git history yourself; that’s Kris’s call once findings are in. Do not act on the visibility recommendation (see overview.md) even if the audit comes back clean — flag it, don’t execute it.

Where the work lands

This workspace repo (the findings report; suggest epics/workspace-dashboard/ or a new file referenced from this task). The audit itself reads both lor-workspace and land-of-lor’s git history — read-only, no commits needed to perform the audit itself.

Docs to read first

overview.md’s “FIRST TASK” section in full (the complete scope, stakes, and the visibility recommendation this gates) — nothing else needed to execute this cold.

View source in repository · also available as raw markdown.